dolfin team mailing list archive

[Faheem Mitha <faheem@xxxxxxxxxxxxx>]

On Sun, 17 Jul 2005, Johan Jansson wrote:

> On Sun, Jul 17, 2005 at 03:02:53AM -0400, Faheem Mitha wrote:

> 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 don't understand. Why is it necesary for DOLFIN to use the alternatives 
system at all? If it is using MPICH libraries explicitly everywhere, I 
don't see the problem, and from what I understand, that is what it is 
doing.

Please elaborate.

> 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.

The standard place for these kinds of discussions is debian-devel. I could 
possibly also file a bug against some Debian package, but I'm not sure 
which. I guess I'll post to debian-devel and take it from there. Feel free 
to post yourself if you wish, since you probably understand the issue 
better than I do.

In the meantime, I'll put a conflicts in libdolfin-dev against lam4-dev 
till this is resolved.

> 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?

Yes, I think you've hit the nail on the head.

> 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.

Yes.

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

This all sounds very reasonable. I see r-base-dev (for example) does 
something similar, so this presumably does not violate anything in policy.

Ok. However, I'll need to split libpetsc into libpetsc and libpetsc-dev to 
get this to work.

> > 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.

Ok.

> > 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.

Ok.

> > 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.

Yes, but I could break up the current library (I think) into libpetsc, 
libpetsc-dev, libpetsc-dbg, libpetsc-dbg-dev. That would help.

> > 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.

In that case, I notice that DOLFIN links to the debug version of the 
shared libraries by default. Presumably it should link to the optimized 
version. How can I change this?

                                                                  Faheem.

faheem@maxwell:/usr/local/src/dolfin/dolfin-0.5.7/src/demo/fem$ ldd dolfin-fem
        libncurses.so.5 => /lib/libncurses.so.5 (0x40028000)
        libpetscts.so => /usr/lib/petsc-2.2.1/lib/libg_c++/linux-gnu/libpetscts.so (0x40067000)
        libpetscsnes.so => /usr/lib/petsc-2.2.1/lib/libg_c++/linux-gnu/libpetscsnes.so (0x4012d000)
        libpetscksp.so => /usr/lib/petsc-2.2.1/lib/libg_c++/linux-gnu/libpetscksp.so (0x40211000)
        libpetscdm.so => /usr/lib/petsc-2.2.1/lib/libg_c++/linux-gnu/libpetscdm.so (0x40490000)
        libpetscmat.so => /usr/lib/petsc-2.2.1/lib/libg_c++/linux-gnu/libpetscmat.so (0x405ce000)
        libpetscvec.so => /usr/lib/petsc-2.2.1/lib/libg_c++/linux-gnu/libpetscvec.so (0x4092f000)
        libpetsc.so => /usr/lib/petsc-2.2.1/lib/libg_c++/linux-gnu/libpetsc.so (0x40a95000)
        liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x40c1e000)
        libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0x4126a000)
        libdl.so.2 => /lib/libdl.so.2 (0x415b3000)
        libg2c.so.0 => /usr/lib/libg2c.so.0 (0x415b6000)
        libm.so.6 => /lib/libm.so.6 (0x415d4000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x415f7000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x41602000)
        libz.so.1 => /usr/lib/libz.so.1 (0x41709000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x4171b000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4176c000)
        libc.so.6 => /lib/libc.so.6 (0x41826000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)