dolfin team mailing list archive

[Johan Jansson <johanjan@xxxxxxxxxxxxxxxx>]

On Sun, Jul 17, 2005 at 03:02:53AM -0400, Faheem Mitha wrote:
> 
> Hi Johan,
> 
> So you use Debian as well?
> 

Yes, I mainly use Debian. I have also started using Ubuntu (which is
based on Debian).

> On Sun, 17 Jul 2005, Johan Jansson wrote:
> 
> >On Sat, Jul 16, 2005 at 04:53:49PM -0400, Faheem Mitha wrote:
> 
> >I discovered I had old PETSc libraries in /usr/lib. When I removed
> >them everything worked like it should. Please check if you have the
> >same situation. The linker must select those libraries first, perhaps
> >because "-L /usr/lib" occurs before the correct PETSc path.
> 
> I've traced the problem to the presence of lam4-dev. If this is installed, 
> the compilation of all the demo examples I've tried go straight to hell. 
> See if you can reproduce this. I've verified this on another machine.
> 
> Without lam4-dev installed, the demos I've tried compile and run Ok.
> 
> I'm not sure what to do about this, but clearly it qualifies as a problem. 
> Please advise.

I've verified this problem. What happens is that lam4-dev replaces the
MPI includes from libmpich1.0-dev with its own
version. /usr/include/mpi is a symlink to /etc/alternatives/mpi, which
alternates between pointing to /usr/lib/mpich/include and
/usr/include/lam depending on whether lam4-dev is installed. There
exists a corresponding library symlink /usr/lib/libmpi.so which also
alternates depending on installation.

However, it seems that DOLFIN is linking directly against mpich,
i.e. this is a fragment of the link flags:

-L/usr/lib/mpich/lib -lmpich

If this is changed to:

-L/usr/lib -lmpi

then linking works as expected.

I'm not sure how to resolve this. It looks to be related to the issue
of implicit dependencies which you talk about below, but it's actually
separate. DOLFIN could have determined on its own to use the flags
"-L/usr/lib/mpich/lib -lmpich", which would still have led to link
errors when installing lam4-dev.

I think the problem is with the /etc/alternatives system and
libraries/includes. Is it really meant to be used with libraries? If
it is, then it's an unsafe system, which our example
demonstrates. Debian switches an include without switching the
corresponding library, I don't see how it's possible to correctly
handle that case. Perhaps this discussion should be continued on some
Debian policy list about the safety of /etc/alternatives?

The quick way to resolve this is to put a note warning against
installing other MPI libraries than mpich (i.e. lam4-dev), since
Debian doesn't guarantee that the MPI headers in /usr/include/mpi can
be used with both libraries.

...

> >This module has been disabled (because it doesn't work yet). So it has
> >been commented out from for example src/modules/Makefile.am, which is
> >why it doesn't get installed. Your fix is probably ok for now, in
> >future releases we will make sure that the makefiles are consistent,
> >i.e. if the module is disabled it should not be used anywhere. Of
> >course the best solution would be if the module worked and could be
> >installed :).
> 
> I'm not completely sure I follow this. Why is it being used in the compile 
> if it is disabled?

This is an error in DOLFIN, it should not be used in the compile.

> >>The following list of build dependencies was generated with the help of
> >>pbuilder. Build, wait for failure, add to build-depends. Repeat.
> >>
> >>debhelper (>= 4.0.0), libxml2-dev, libpetsc, libncurses5-dev, mpich-bin,
> >>libmpich1.0-dev, lapack3-dev, refblas3-dev | atlas3-base-dev
> >>
> >>Note that the configure script does not look for anything after PETSc, as
> >>far as I can tell. Adding tests for the other things should be easy.
> >
> >Apart from debhelper (which I don't understand why it's included),
> 
> Debhelper is a Build Depends since the rules files uses it, and so the 
> package will not build without it.
> 
> >all libraries following libncurses5-dev are dependencies of
> >PETSc. So if DOLFIN finds a working PETSc, then they must
> >exist. There are no explicit dependencies on those libraries from
> >DOLFIN. Shouldn't it be enough then to only check for PETSc?
> 
> It is true that the Build-Depends of petsc include these packages. 
> However, this is not the same as the runtime dependencies ('Depends' for 
> short). I don't see why any of these dev packages should be runtime 
> dependencies of PETSc, and they are not currently listed as such.
> 
> In other words, the Build-Depends of petsc cannot be guaranteed to be 
> available at the build time of dolfin, since there is nothing pulling them 
> in (as far as I can see). If I am missing something, please enlighten me.
> 
> I repeat, the configure script ought to look for these.
> 

I think there's some confusion between "runtime" and "build time", and
the different dependencies which apply for each. As far as I can see,
both PETSc and DOLFIN are dev packages. Then they should not have any
runtime dependencies at all, correct? Or should PETSc have both a
runtime package libpetsc and a dev package libpetsc-dev? Is that the
source of the confusion?

As far as I can see, the PETSc package which libdolfin-dev depends on
must depend on the LAPACK and BLAS dev packages, and then it should be
enough for DOLFIN to check only against PETSc, since PETSc will pull
in the other required dev packages. And since a dev package always (as
far as I can see) depends on the corresponding runtime package, the
issue would be solved.

So the dependency tree should look something like this:

libpetsc-dev: libpetsc, libblas-dev, liblapack-dev

libdolfin-dev: libpetsc-dev

The reason for having a runtime package is because PETSc provides
shared libraries, which contain executable code. DOLFIN doesn't
provide any shared libraries or other executable binaries, so it
doesn't need a runtime package.

I don't know how MPI should be handled, I'm not familiar enough with
it. The simplest solution would be to treat it as LAPACK or any other
library, which would mean that libpetsc-dev should depend on
libmpich-dev and DOLFIN should not.

This is how the previous PETSc package worked, why is that model not
valid?

> >>>Something for visualization (MATLAB, Octave, OpenDX, GiD, Tecplot or
> >>>Paraview/VTK). This is more post run-time.
> >>
> >>Most of these look proprietary. Perhaps Octave in a suggests?
> >
> >Yes, definitely. Open Inventor (inventor-clients) should also be a
> >suggests since it's used in some visualization scripts (pdeplot.m).
> 
> Ok. Should I add inventor-clients and octave to suggests of libdolfin or 
> libdolfin-dev? If there is only going to be libdolfin-dev (see below) then 
> there is nothing to decide.
> 

There should only be libdolfin-dev. The OpenDX package "dx" should
also be in suggests, it's not proprietary and is also used in some
DOLFIN visualization scripts.

> >>One (fairly important) question with regard to this. If I link against the
> >>DOLFIN static libraries, then should I still require these libraries at
> >>runtime? I'd have thought not, but based on preliminary evidence, this
> >>does not appear to be the case.
> 
> >No, this cannot be the case. When linking, the contents of a static 
> >library is included in the executable and no reference to the library is 
> >kept. The linking problem must have been because of the old PETSc 
> >libraries or something similar. If it isn't, please post the errors you 
> >get and let's try to find the problem.
> 
> Ok, thanks for the confirmation.
> 
> As for the linking problem, see above. The culprit is different versions 
> of MPI. I guess I should move the static libraries into libdolfin-dev as 
> per Debian policy. So there will be no libdolfin package till shared 
> dolfin libraries are generated. Any objections to this?

No objections, this is the correct solution.

> 
> Ok, just a couple more things.
> 
> It appears at least some of the demos do not compile without mpich1.0-dev 
> being installed. What should be the status of this? Should it be a 
> recommends or a suggests?

libpetsc-dev should depend on this, so it should be pulled in
automatically.

> 
> libpetsc is too big. Please suggest how its size could be reduced. Also, 
> do you have any suggestions on how the runtime and dev libraries could be 
> split up?

I don't think you should worry about the size. The libraries are big,
there's not much to do about it. As far as I can see, the runtime
libraries are the shared libraries.

> 
> I also notice that the executables in demo are linking against 
> /usr/lib/petsc-2.2.1/lib/libg_c++. Remind me what this is, and why do we 
> also need /usr/lib/petsc-2.2.1/lib/libO_c++?

libO is apparently the optimized version and libg is debug.

  Johan