Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Building Perl with static and dynamic perllib libs

by bergbrains (Acolyte)
on Nov 10, 2011 at 17:27 UTC ( #937417=perlquestion: print w/ replies, xml ) Need Help??
bergbrains has asked for the wisdom of the Perl Monks concerning the following question:

I'm updating our environment with new perls, and have run into a few gotchas. I'm using perlbrew.

First, the default for building perl does not generate libperl.so, so I had to include the following params:

-Duselargefiles -Dcccdlflags=-fPIC -Doptimize=-O2 -Duseshrplib -Duse64bitall

I believe the only parameter relevant to the building of libperl.so instead of libperla is -Dusesshrplib

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 for those hosts of ours that do not have the sybase libraries installed.

Can anyone tell me how to build perl so that a) I get both libperl.so and libperl.a? Admittedly, I don't understand the larger issues surrounding the building as static/dynamic, but I need to know if it can be done, so any help would be appreciated

Comment on Building Perl with static and dynamic perllib libs
Download Code
Re: Building Perl with static and dynamic perllib libs
by Eliya (Vicar) on Nov 10, 2011 at 19:08 UTC
    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...)

Reaped: Re: Building Perl with static and dynamic perllib libs
by NodeReaper (Curate) on Nov 14, 2011 at 12:53 UTC
Reaped: Re: Building Perl with static and dynamic perllib libs
by NodeReaper (Curate) on Nov 15, 2011 at 13:33 UTC
Re: Building Perl with static and dynamic perllib libs
by mpeppler (Vicar) on Nov 17, 2011 at 07:36 UTC
    Keep in mind that even without the actual libraries (libsybct.so, etc) you will still need a number of other Sybase files (locale files, charset files) available locally. So just linking statically won't completely resolve the issue of not having Sybase client software installed.

    Michael

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://937417]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2014-11-01 10:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (229 votes), past polls