[Petsc-trilinos-discussion] Scope and requirements

[Jed Brown]

"Bartlett, Roscoe A." <bartlettra at ornl.gov> writes:

> Then what is the issue with shared vs static libs? Why can't
> downstream client app just compile the petsc ml adapter, 
> call the registration func then use ml under petsc like before?

This is what I called a "terrible interface" in my earlier email
<87eh6857n8.fsf at jedbrown.org>.

The client app is not _implementing_ the ML plugin, so they shouldn't
have to compile it or register it.

With shared libraries, a libpetsc-ml.so can be built at any time and
dropped in a directory that gets loaded.  So the user client app links
oblivious to the existence of an ML plugin, which may not have even been
built yet.  The plugin can be distributed separately, but if it's in the
plugins directory, the app can use it via run-time options.

You can't do that with static libraries because you don't have dlopen,
but you can use __attribute((constructor)) so that the plugin is
automatically registered when libpetsc-ml.a is linked.  That is at best
a mediocre interface because the client app has to be aware of the
plugin in order to add -lpetsc-ml to the link line, but static libraries
don't give us many options.
-------------- 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-trilinos-discussion/attachments/20131122/0476d6bd/attachment.pgp>