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