[petsc-dev] circular dependencies SLEPc

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Mon, Jul 8, 2019 at 10:37 PM Jed Brown via petsc-dev <
> petsc-dev at mcs.anl.gov> wrote:
>
>> "Smith, Barry F. via petsc-dev" <petsc-dev at mcs.anl.gov> writes:
>>
>> >> On Jul 8, 2019, at 9:53 PM, Jakub Kruzik via petsc-dev <
>> petsc-dev at mcs.anl.gov> wrote:
>> >>
>> >> Just to clarify, the suggested solution is a plug-in sitting anywhere
>> in the PETSc source tree with postponed compilation and using
>> __attribute__((constructor)) to register (as in libCEED) for static
>> libraries?
>> >
>> >   Yes, this is my understanding. Good luck.
>>
>> There is some nontrivial infrastructure that would be needed for this
>> model.
>>
>> 1. This new component needs to be built into a new library such as
>>    libpetsc-plugin.a (when static).
>>
>> 2. Users need to know when they should link this module.  They'll need a
>>    link line something like -lpetsc-plugin -lslepc -lpetsc in this case.
>>    It would need to be specified correctly in makefiles and pkg-config.
>>
>> 3. Anything with __attribute__((constructor)) runs *before* main, thus
>>    before PetscInitialize.  There would need to be a new mechanism to
>>    register a callback to be run at the end of PetscInitialize.
>>
>
> I think the simpler course it just to declare that this does not work
> outside of dynamic linking.
> The number of platforms that do not have dynamic linking is small, and we
> are not putting
> anything critical here. This decision can be reevaluated, but for now it
> makes everything much
> much simpler.

For the library to be loaded automatically, you would define a runpath,
perhaps defaulting to

  $(dirname /path/to/lib/libpetsc.so)/petsc/plugins

that would be scanned and each shared library in that directory would be
PetscDLLibraryOpen'd?