[petsc-dev] now that we have -lpetsc should we also have #include "petsc.h"?
Satish Balay
balay at mcs.anl.gov
Fri Feb 26 10:48:27 CST 2010
One note on this scheme wrt linux..
Fedora is making it illegal for appliation to link *only* to
libpetsc.so [if libpetsc.so relies on lipetscsys.so etc..]
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange
perhaps other linux distos will do the same..
Satish
On Fri, 26 Feb 2010, Lisandro Dalcin wrote:
> On 26 February 2010 00:20, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> > On Feb 25, 2010, at 9:18 PM, Lisandro Dalcin wrote:
> >
> >> On 25 February 2010 23:19, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >>>
> >>> One mistake below, it would be petscsys.h not petsccore.h
> >>>
> >>
> >> Cool.
> >>
> >> BTW, in the case of --with-single-library=0, Will we still have a
> >> dummy libpetsc.so linked against the others libpetscxxx.so ?
> >
> > If you tell us how to make it portably.
> >
>
> 1) On Linux this is trivial. Moreover, look at the ld.so manpage,
> under $ORIGIN and rpath section. On Solaris all this should be doable
> (and likely trivial, too).
>
> BTW, the whole point of $ORIGIN is to avoid using absolute RPATH's ...
>
> As a quick test on Linux, you could:
>
> $ export PETSC_DIR=$PWD PETSC_ARCH=multi-lib
>
> $ ./configure --with-shared=1 --with-single-library=1 && make
>
> $ cd multi-lib/lib
>
> $ gcc -shared -o libpetsc.so -Wl,-rpath,'$ORIGIN' -L. -lpetscsys
> -lpetscvec -lpetscmat -lpetscdm -lpetscksp -lpetscsnes -lpetscts
>
> $ readelf -d libpetsc.so | head -n 12
>
> Dynamic section at offset 0x4a0 contains 28 entries:
> Tag Type Name/Value
> 0x00000001 (NEEDED) Shared library: [libpetscsys.so]
> 0x00000001 (NEEDED) Shared library: [libpetscvec.so]
> 0x00000001 (NEEDED) Shared library: [libpetscmat.so]
> 0x00000001 (NEEDED) Shared library: [libpetscdm.so]
> 0x00000001 (NEEDED) Shared library: [libpetscksp.so]
> 0x00000001 (NEEDED) Shared library: [libpetscsnes.so]
> 0x00000001 (NEEDED) Shared library: [libpetscts.so]
> 0x00000001 (NEEDED) Shared library: [libc.so.6]
> 0x0000000f (RPATH) Library rpath: [$ORIGIN]
> [dalcinl at trantor lib]$ ldd libpetsc.so | head -n 9
> linux-gate.so.1 => (0x00692000)
> libpetscsys.so =>
> /u/dalcinl/Devel/PETSc/petsc-dev/multi-lib/lib/./libpetscsys.so
> (0x006cf000)
> libpetscvec.so =>
> /u/dalcinl/Devel/PETSc/petsc-dev/multi-lib/lib/./libpetscvec.so
> (0x00110000)
> libpetscmat.so =>
> /u/dalcinl/Devel/PETSc/petsc-dev/multi-lib/lib/./libpetscmat.so
> (0x0081f000)
> libpetscdm.so =>
> /u/dalcinl/Devel/PETSc/petsc-dev/multi-lib/lib/./libpetscdm.so
> (0x00cbb000)
> libpetscksp.so =>
> /u/dalcinl/Devel/PETSc/petsc-dev/multi-lib/lib/./libpetscksp.so
> (0x001fa000)
> libpetscsnes.so =>
> /u/dalcinl/Devel/PETSc/petsc-dev/multi-lib/lib/./libpetscsnes.so
> (0x00429000)
> libpetscts.so =>
> /u/dalcinl/Devel/PETSc/petsc-dev/multi-lib/lib/./libpetscts.so
> (0x00fb3000)
> libc.so.6 => /lib/libc.so.6 (0x0051b000)
>
>
> 2) On OS X, I'm not sure the exact meaning of all the stuff at the
> very end of http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
> ... We should investigate how @loader_path and @rpath work for
> libraries (if they work at all, that page seems to refer on final
> executables)
>
> 3) On Windows, well, you know, DLL handling is a mess...
>
> So, Barry, if we cannot make it work on ALL target platforms, that
> mean that we are not going to do it for ANY of them? IMHO, I do not
> see the point. If we can provide a single link entry point
> (libpetsc.so) for the multi-lib case on Linux (and likely Solaris), we
> should. Regard this as a convenience for end users: Linux(&Solaris?)
> (and likely any system using ELF format) users that do not care about
> other platforms just need to pass -lpetsc to the linker, and things
> will work despite the value of --with-single-library...
>
>
>
More information about the petsc-dev
mailing list