Two XS modules linked to one .a library.

[Bill Moseley]

I have a simple, if not basic, question.

We have a static archive (*.a) library provided to us that we have written an XS interface for.   So, the resulting .so that XS builds contains that library (or whatever the linker decided to include, I suppose).

New functionality was added to that static library and we created a separate XS module for just that functionality.   It also pulls in much (all?) of that .a library when building the Perl XS .so module.

Is there potential for symbols to "clash" in this situation?   Or is that not a problem as long as the .a library was compiled with -fPIC?

We are using both the XS Perl modules in the same process and seems to work fine.   So, not sure if that is just luck or if there's no problem doing this.

If we can get the library rebuilt as a .so would that make much of a difference?

I'm running on CentOS and non-threaded Perl, if that makes a difference.

Thanks,

--
Bill Moseley
mos...@hank.org

[sisy...@optusnet.com.au]

From: Bill Moseley
Sent: Tuesday, September 30, 2014 10:39 PM

> Is there potential for symbols to "clash" in this situation?

No.
It should not be possible for the set up you described to result in a
"clash" of XS symbols, no matter how hard you try. The XS symbols are
private to both modules - it doesn't matter if identical symbols exist.

IIUC, you'd have to have one module's .so also load the other module's .so
(which, I think, can be achieved using ExtUtils::Depends in the build
process) in order to stand a chance of creating a clash.

Cheers,
Rob

[Bill Moseley]

On Tue, Sep 30, 2014 at 7:36 AM, <sisy...@optusnet.com.au> wrote:

No.
It should not be possible for the set up you described to result in a "clash" of XS symbols, no matter how hard you try. The XS symbols are private to both modules - it doesn't matter if identical symbols exist.

Thanks for the quick reply, Rob.

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.

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.

Thanks again.

--
Bill Moseley
mos...@hank.org

[sisy...@optusnet.com.au]

From: Bill Moseley
Sent: Wednesday, October 01, 2014 1:12 AM
To: per...@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

[sisy...@optusnet.com.au]

From: Bill Moseley
Sent: Wednesday, October 01, 2014 1:12 AM
To: per...@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.

Afterthought:

The 3rd party .a library is not really "shared".
When you build a module against it, the .a library's functionality gets
incorporated into the functionality of the module's .so file.
After the build, you can rename the .a file or entirely remove it from the
system, and the module will remain fully functional.

Cheers,
Rob