Compile perlbrew with libperl.so versus libperl.a-CodePudding

I've been working on moving some software from RHEL 7 to Ubuntu 22.04.

I utilize Perlbrew. When I built the new 5.36.0 everything seemed normal until I started working on compiling mod_perl for my apache servers.

I built perlbrew with this:

perlbrew install perl-5.36.0 --as=perl-5.36.0 -Duseithreads

Then I tried compiling mod_perl. It flopped while trying to use the libperl.a library. I hit an error:

/usr/bin/ld: /perl5/perls/perl-5.36.0t/lib/5.36.0/x86_64-linux-thread-multi/CORE/libperl.a(op.o): relocation R_X86_64_PC32 against symbol `PL_hash_state_w' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value

I did the googling and I think I'm trying to do a 'make' against a library that is static versus a shared object library? I may have the wrong idea but I'm chasing down this in hopes of solving the issue or finding more info along the way.

How do I set perlbrew install options to compile this as a .so library in Ubuntu just like it is in my previous version in RHEL?

/perl5/perls/perl-5.26.2/lib/5.26.2/x86_64-linux-thread-multi/CORE/libperl.so

Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 7.6 (Maipo)
Release: 7.6
Codename: Maipo

/perl5/perls/perl-5.36.0/lib/5.36.0/x86_64-linux-thread-multi/CORE/libperl.a
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy

TIA

Perlbrew installed without issues, but apache mod_perl won't compile unless it has a libperl.so versus a libperl.a library. Trying to figure out how I force the installer to create libperl.so versus libperl.a that's in there now.

CodePudding user response：

INSTALL from 5.36.0 says:

Building a shared Perl library

Currently, for most systems, the main perl executable is built by linking the "perl library" libperl.a with perlmain.o, your static extensions, and various extra libraries, such as -lm.

On systems that support dynamic loading, it may be possible to replace libperl.a with a shared libperl.so. If you anticipate building several different perl binaries (e.g. by embedding libperl into different programs, or by using the optional compiler extension), then you might wish to build a shared libperl.so so that all your binaries can share the same library.

The disadvantages are that there may be a significant performance penalty associated with the shared libperl.so, and that the overall mechanism is still rather fragile with respect to different versions and upgrades.

In terms of performance, on my test system (Solaris 2.5_x86) the perl test suite took roughly 15% longer to run with the shared libperl.so. Your system and typical applications may well give quite different results.

The default name for the shared library is typically something like libperl.so.5.8.8 (for Perl 5.8.8), or libperl.so.588, or simply libperl.so. Configure tries to guess a sensible naming convention based on your C library name. Since the library gets installed in a version-specific architecture-dependent directory, the exact name isn't very important anyway, as long as your linker is happy.

You can elect to build a shared libperl by
sh Configure -Duseshrplib
[snip]

So you would pass -Duseshrplib to perlbrew install.