[petsc-dev] now that we have -lpetsc should we also have #include "petsc.h"?

Barry Smith bsmith at mcs.anl.gov
Fri Feb 26 13:22:32 CST 2010


On Feb 26, 2010, at 10:30 AM, 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?

    No, I didn't mean that.  It is ok to support it only sometimes  
(since one can always use single library on the other systems if they  
really want one library).

    Barry


> 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...
>
>
> -- 
> Lisandro Dalcin
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594




More information about the petsc-dev mailing list