My department's production servers (RHEL5) have no access to the Internet or any CPAN repository. Therefore, when we need to use a specific Perl module with our scripts, we download them to our terminals from the CPAN website, scp them over to our dev machines, untar them, and then build them locally. We then distribute them to a shared network file system so that other developers may use them, and so that they are available on the prod machines as well. In this way we build a library of Perl modules that slowly grows over time. 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 (and is frequently 5.8.8, which is outdated for a few necessary modules). 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. I have tried to rebuild the local Perl using the 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. My system Perl actually used many more Configure options, but since I was so unfamiliar with them, I didn't throw them into the local Perl build for obvious precautionary reasons.

First, can someone help me get a better understanding of what is preventing these modules from working with my locally built Perl? It makes sense that modules would not work under different versions of Perl, but it surprises me that it doesn't work with the same version built on the same machine. It also does not make sense to me that a module would lock itself info a specific Perl build like a "license" type scenario, so my intuition is that the module is incompatible with some unseen setting/library that the local Perl is built under.

Second, is there a way to get my locally built Perl to work with the modules compiled with the system Perl, or will I have to recompile them all and redistribute a fresh set of modules?

Thank you for any and all help! I have tried Googling the answer, but any issues dealing with this only bring up different Perl versions, which is not the situation I am currently facing.

UPDATE AND SOLUTION

First off, thank you to all those who responded. I wanted to say definitely 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!

So, I guess I spent a lot of time trying to put this whole question together. But at least now the Internet (and Perl Monks) will have a definitive answer if others have the same problem.

In reply to Can I re-use modules compiled with a different build of Perl, but with the same version number on the same machine? by neuty

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.