Matthew Knepley <knep...@gmail.com> writes: > On Mon, Jul 8, 2019 at 10:37 PM Jed Brown via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> "Smith, Barry F. via petsc-dev" <petsc-dev@mcs.anl.gov> writes: >> >> >> On Jul 8, 2019, at 9:53 PM, Jakub Kruzik via petsc-dev < >> petsc-dev@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?