From: Bill Moseley
Sent: Wednesday, October 01, 2014 1:12 AM
To: perl-xs@perl.org
Subject: Re: Two XS modules linked to one .a library.
Just to clarify I was meaning the symbols in the shared third-party .a
library. Where two separate Perl (XS) modules link to the same static .a
library and those two Perl modules are then used in the same program.
Yep - that's as I took it to be.
Neither of those perl modules knows (nor needs to know) anything about the
contents of the other module's .so.
The linking to the .a library is all done when the module is compiled. As
long as that worked, your only concern is avoiding having both modules
export a sub of the same name - in which case you'll get a "subroutine
redefined" warning, anyway (if you've turned warnings on).
We are going to try and get the .a library built as a .so file (or really
many .so libraries). As it is right now it's kind of a beast so the
resulting Perl XS-build .so files are quite big. Seems like a cleaner
approach, and that would allow patching the third-party library w/o having
to rebuild the Perl modules.
One interesting side note about using 2 perl modules (that access the same
library) being used in the *same process*:
Let's call the modules FOO and BAR, and assume they both contain a
set_global() function and a get_global() function.
The set_global() function sets a *C library* global to some value, and the
get_global() function returns the current value of that library global.
If you've built both FOO and BAR against a static library, then altering the
value of the global by running FOO::set_global($newval) won't have any
effect on the value returned by BAR::get_global(), which will remain
unchanged. (And vice-versa.)
But if you've built FOO and BAR against a shared library, then both
BAR::get_global() and FOO::get_global() will always return identical
values - and the value returned will be whatever the most recent
set_global() call specified (irrespective of which module made that call).
If your modules happen to both be capable of setting a particular library
global, you should be able to verify that quite easily.
Of course, if both FOO and BAR are being run in separate processes, then
there's no such issue. (Not sure what happens when FOO and BAR, built
against the same shared library, are run in different threads of the same
process ... I'm guessing it might depend upon the thread-safety of the
shared library.)
Math::GSL is one module where this is a consideration. There's an option to
set an error handling global - but that turns out to be not at all global if
Math::GSL is built against a static gsl library, because all of the
Math::GSL sub-modules have their own .so linked to the static gsl library.
This is just like the situation you've outlined for your current setup,
except Math::GSL has about 30 modules, not just 2.
Cheers,
Rob
