dolfin team mailing list archive

[Johan Jansson <jjan@xxxxxxxxxxx>]

Hi!

I'm helping a colleague to update his solver to the dolfin-fsi
repository, but we are hitting an unexpected snag in linking.

The solver is stand-alone, so all we are doing is compiling a few .cpp
files and linking into an executable. The structure is similar to the
src/demo/pde/euler solver.

However, after linking, the shared library dependencies look like this:

        libdolfin.so.0 => /afs/nada.kth.se/dept/na/hacks/pkg/dolfin/fsi/@sys/lib/libdolfin.so.0 (0x00111000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00a51000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00765000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a47000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00893000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00638000)
        libpetscmat.so => not found
        libpetscvec.so => not found
        libutil.so.1 => /lib/libutil.so.1 (0x00dbb000)
        libpetscts.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/@sys/lib/linux-gnu-cxx-debug/libpetscts.so (0x003a7000)
        libpetscsnes.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/@sys/lib/linux-gnu-cxx-debug/libpetscsnes.so (0x00237000)
        libpetscksp.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/@sys/lib/linux-gnu-cxx-debug/libpetscksp.so (0x00dbf000)
        libpetscdm.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/@sys/lib/linux-gnu-cxx-debug/libpetscdm.so (0x002a9000)
        libpetscmat.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/@sys/lib/linux-gnu-cxx-debug/libpetscmat.so (0x0238a000)
        libpetscvec.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/@sys/lib/linux-gnu-cxx-debug/libpetscvec.so (0x0047b000)
        libpetsc.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/@sys/lib/linux-gnu-cxx-debug/libpetsc.so (0x008a5000)
...

Whereas for the euler demo (and for all other demos) it looks like this:

        libdolfin.so.0 => /afs/nada.kth.se/home/o/u1mb1o3o/usr/lib/libdolfin.so.0 (0x00a16000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00111000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00765000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x001dc000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00893000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00638000)
        libutil.so.1 => /lib/libutil.so.1 (0x00dbb000)
        libpetscts.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug/libpetscts.so (0x008e2000)
        libpetscsnes.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug/libpetscsnes.so (0x00b3c000)
        libpetscksp.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug/libpetscksp.so (0x001e4000)
        libpetscdm.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug/libpetscdm.so (0x004e7000)
        libpetscmat.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug/libpetscmat.so (0x00dbf000)
        libpetscvec.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug/libpetscvec.so (0x00bae000)
        libpetsc.so => /afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug/libpetsc.so (0x05d7d000)
...

Does anyone have an idea why the PETSc libraries are added twice in
the first case? 

I suspect this has something to do with the automatic dependency
generation of dolfin.so mentioned in this changeset:

http://www.fenics.org/hg/dolfin?cs=aae268f6697f

When we link, the link flags look like:

LIBS = `pkg-config --libs dolfin`

which evaluates to:

LIBS = -L/afs/nada.kth.se/dept/na/hacks/pkg/dolfin/fsi/i386_linux26/lib

If we change this back to how it was in dolfin-stable:

LIBS = -Wl,-rpath,/afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug -L/afs/nada.kth.se/dept/na/hacks/pkg/dolfin/fsi/i386_linux26/lib -L/afs/nada.kth.se/dept/na/hacks/pkg/petsc/2.3.2/petsc/lib/linux-gnu-cxx-debug -ldolfin -lncurses -lpetscts -lpetscsnes -lpetscksp -lpetscdm -lpetscmat -lpetscvec -lpetsc -lxml2 -lz -lpthread -lm

Everything works fine and we don't get the repeated and missing PETSc
library entries.

If nobody has an idea I'll try to write a simple test case and figure
out what goes wrong.

  Johan