[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