The conundrum I'm in is that I need libperl.so to build mod_perl and libperl.a to build a static version of DBD::Sybase

Your best bet is probably to run the build twice, once with -Duseshrplib and once without.  And then install whichever variant of perl you want (static/dynamic), manually copying the missing libperl from the other build next to the already installed one. For example, if you install the statically linked perl binary, libperl.a will get installed together with it, so just copy the libperl.so from the other build next to it (in the same directory).

But note that if you have both a static and a dymanic library in the same location, the linker (ld) will by default link against the dynamic one (so if you don't want this to happen, the easiest approach is typically to just move it away temporarily while building whatever needs the static lib...).

That said, it might be wiser to simply install both versions into separate directories, because then the configuration information (i.e. essentially what you get via "perl -V") will automatically be correct without manual tweaking.

BTW, what exactly do you mean by "build a static version of DBD::Sybase"?  Are you building an extra perl binary that already includes the XS part of the DBD::Sybase module statically (as opposed to loading the extension at runtime via DynaLoader)? Otherwise, I wouldn't know why you would need a libperl.a for that.  If it's only because you don't want to have dependencies on shared sybase libs, you should (in theory) be able to link the sybase code/libs statically into a shared XS lib (i.e. Sybase.so) and still have that library loaded at runtime from either a statically or a dynamically linked perl binary (in which case that XS lib would no longer depend on the third party sybase libs — at runtime, that is, at build-time you of course need them).

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

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...)

Michael