[petsc-dev] Why --with-dynamic-loading?

Jed Brown jedbrown at mcs.anl.gov
Thu Aug 29 13:14:12 CDT 2013


Barry Smith <bsmith at mcs.anl.gov> writes:

>   Originally BuildSystem should have checked that dynamic libraries
>   worked. But now we have PETSC_HAVE_DYNAMIC_LIBRARIES that checks if
>   dynamic libraries work and and PETSC_USE_DYNAMIC_LIBRARIES that
>   indicate PETSc should use them. The USE requires that the HAVE
>   checked passed. So we would only support the -dynamic_library flag
>   if HAVE is true.

Yup, I still don't know if it's useful, but if we're keeping that
option, it has to be guarded by PETSC_HAVE_DYNAMIC_LIBRARIES.

>    Without the guard the symbols such as KSPRegisterAll() etc are
>    directly visible at link time and this means all the symbols in all
>    the implementations are visible. With the guard KSPRegisterAll() is
>    only seen AFTER the dynamic load (and all symbols it knows
>    about). The idea is that impls symbols are delayed in the dynamic
>    case.  Now does anyone care about this, I don't know?

All the symbols relocations are done when the shared library is first
loaded (e.g., in ld.so or in dlopen), _not_ the first time they are
used.  So the distinction is only relevant if you move the impls to
separate shared libraries (along with KSPRegisterAll).  Unless I'm
missing something, we _can't_ care with the current system and if we
redesigned to be able to care, the system would have to be modified
slightly anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130829/e2fad1a8/attachment.sig>


More information about the petsc-dev mailing list