Re^2: Building Perl with static and dynamic perllib libs

you should (in theory) be able to link the sybase code/libs statically into a shared XS lib (i.e. Sybase.so)

Yes - that struck me, too.
To take the point a bit further, I believe you should be able to build DBD::Sybase against either a static or dynamic sybase library (the choice is yours), irrespective of whether perl's "libperl" is libperl.a or libperl.so.

Cheers,
Rob

Comment on Re^2: Building Perl with static and dynamic perllib libs

Replies are listed 'Best First'.
Re^3: Building Perl with static and dynamic perllib libs by Eliya (Vicar) on Nov 11, 2011 at 01:53 UTC
I believe you should be able to build DBD::Sybase against either a static or dynamic sybase library (the choice is yours), irrespective of whether perl's "libperl" is libperl.a or libperl.so. That's correct, both with respect to libperl(.so\|.a) not being of relevance here as well as with respect to static vs. dynamic linking of the sybase libs. I only mentioned statically linking the sybase libs, because I was under the impression the OP's problem in part revolved around not wanting external dependencies ("...for those hosts of ours that do not have the sybase libraries installed."). You can of course also link against dynamic sybase libs (which would be the "normal" thing to do), but then the respective .so files would need to be available at runtime when Perl's DynaLoader loads the Sybase.so XS extension via `dlopen()`. Similar circumstances hold for libperl.a vs libperl.so, In other words, the static version is only ever needed at build time. Once a static perl binary (or some other executable that statically embeds a Perl interpreter) has been built, the code has become part of the binary, and libperl.a is no longer needed at runtime. Not so with libperl.so, though, if you have a dynamically linked perl binary. (I'm sure you know, but...)	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Building Perl with static and dynamic perllib libs
by Eliya (Vicar) on Nov 11, 2011 at 01:53 UTC

I believe you should be able to build DBD::Sybase against either a static or dynamic sybase library (the choice is yours), irrespective of whether perl's "libperl" is libperl.a or libperl.so.

That's correct, both with respect to libperl(.so|.a) not being of relevance here as well as with respect to static vs. dynamic linking of the sybase libs.

I only mentioned statically linking the sybase libs, because I was under the impression the OP's problem in part revolved around not wanting external dependencies ("...for those hosts of ours that do not have the sybase libraries installed."). You can of course also link against dynamic sybase libs (which would be the "normal" thing to do), but then the respective .so files would need to be available at runtime when Perl's DynaLoader loads the Sybase.so XS extension via dlopen().

Similar circumstances hold for libperl.a vs libperl.so, In other words, the static version is only ever needed at build time. Once a static perl binary (or some other executable that statically embeds a Perl interpreter) has been built, the code has become part of the binary, and libperl.a is no longer needed at runtime. Not so with libperl.so, though, if you have a dynamically linked perl binary. (I'm sure you know, but...)

[reply]
[d/l]