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