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

[Lisandro Dalcin]

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


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