Can I re-use modules compiled with a different build of Perl, but with the same version number?

1
votes

Cross-post from Perl Monks: http://www.perlmonks.org/?node_id=1115125

My department needs to compile its Perl modules manually, which it then uploads to a network shared file system for the developers to share and use. Our current set of modules were built using my system Perl, which /usr/bin/perl -V lists as revision 5 version 10 subversion 1.

However, we're interested in building a separate copy of Perl that we can also upload to the networked file system. This way we are not tied to using each of our machines' system Perl, which can change from machine to machine. A sort of "central" Perl that can be standard across each machine.

Therefore, I needed to build a local copy of Perl in my home directory. I made sure to install the same version as my system Perl, perl-5.10.1. I did this using the following Configure followed by a simple make,make test, make install:

./Configure -des -Dprefix=/home/myuser/localperl -Duserelocatableinc

-Dprefix installed it to the folder localperl in my home directory, while the -Duserelocatableinc flag made it so the @INC would change if the folder was moved (ie., uploaded to the networked file system).

The issue comes when I try to test it out with one of my scripts that requires a module from our library of manually built Perl modules. I keep getting the following error:

/home/myuser/localperl/bin/perl: symbol lookup error: .../auto/DBI/DBI.so: undefined symbol: Perl_Istack_sp_ptr

Obviously my script uses the shared DBI module but is running into errors. From doing research on the Internet, people have said that I would need to recompile the modules using the new build of Perl.

However, the two Perls are the same version and were built on the same machine. Can someone help me get a better understanding of what is preventing these modules from working with my locally built Perl? I have tried to rebuild the local Perl using Configure settings as close to the machine Perl as possible to try to see if that would work:

-Dversion=5.10.1 
-Dmyhostname=localhost 
-Dcc=gcc 
-Dinc_version_list=5.10.0 
-Darchname=x86_64-linux-thread-multi 
-Dusethreads 
-Duseithreads 
-Duselargefiles

So far this has not stopped the error. Is there a way to get my locally built Perl to work with the modules compiled with the machine Perl, or will I have to recompile them all and redistribute a fresh set of modules?

1
perlperl-module
Why aren't using perlbrew and cpanm they're the usual solution for your kind of setup and normally prevent those problems. – Patrick J. S.
The short answer is that I inherited my department's existing infrastructure. However, could you elaborate on how these two modules prevent the issue I am having? My impression is that perlbrew is used for managing different Perl builds on the same machine. Does it somehow make Perl modules compatible across different builds? Also, cpanm is not much use to us. We have no access to the Internet or any CPAN repository from our machines (hence why we manually compile our modules). So recompiling modules for each new Perl build would require building everything from scratch. – YonkeyDonk64
My feelings for you, that sound like really harsh working conditions. As said, perlbrew is the usual way to use custom perl builds in the homedir. And it sets up cpanm to install the modules for each perl version. As you're not allowed to install from the internet: You can set up your own local cpan mirror with pinto, darkpan or OrePan and use that as the only the -M option. The use it would provide is that you'll only have to type one command (cpanm --installdeps with the appropriate META file) and you'll have all the modules set up in the right place of your @INC. – Patrick J. S.
That local CPAN mirror actually sounds pretty useful, thank you. I've proposed something similar in the past, but it did not pick up traction. I'll continue trying to get our current solution to work, but I'll investigate those other options as a possible alternative long-term solution. – YonkeyDonk64
perlmonks.org/?node_id=1115125 – choroba

1 Answers

0
votes

It turns out that, YES, you can re-use modules compiled with different builds of Perl that have the same version number. The trick, as stated above, is to build your localperl with the ./Configure flags as close as possible to your system Perl. You can determine the ./Configure flags your system Perl uses by running perl -V. You should then use those settings with the flags listed above. My intuition is that -Dcc= and -Darchname= are the critical ones to match, though I have not had time to test this assumption.

So, what was my problem if I had already done all of this, and it still wasn't working? Simple - the test script! In my shebang line, I was still pointing to a faulty build of Perl that I had compiled earlier that day! D'oh! Once I pointed the script to the new build with all of the extra ./Configure options, it worked perfectly fine and was able to use all of the modules built with system Perl.