[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