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

Barry Smith bsmith at mcs.anl.gov
Thu Aug 29 13:18:41 CDT 2013


On Aug 29, 2013, at 1:14 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

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

   So what is the proposal? Convert to runtime option (and change) #ifdef ? And remove ifdef from the around the various KSPPackageInitialize()?

  I guess that is fine.

   Barry





More information about the petsc-dev mailing list