Re: Two XS modules linked to one .a library.

From: Bill Moseley
Sent: Wednesday, October 01, 2014 1:12 AM
To: [email protected]
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