perl -le 'print $];'
[download]

perl -V:archname
[download]

I would've expected that if both perls report the same version number, and the same archname then you shouldn't be experiencing this problem

It turns out, you were 100% correct. The local Perl built using the same version and specified archname (using the ./Configure flags mentioned above in my post) did fix the problem. The real issue it turns out was the test script that was pointing to a faulty build of Perl.

http://stackoverflow.com/questions/28239677/can-i-re-use-modules-compiled-with-a-different-build-of-perl-but-with-the-same

It's considered polite to inform about crossposting so people not attending both sites don't waste their efforts hacking a problem already solved at the other end of the Internet.

Crap, I had no idea this was considered impolite! I'll watch what I do in the future!

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.

Mock + cpanspec is often a lot easier. You can build RHEL5 binary RPMs on any RHEL/Fedora and just scp them over, or pop then in a yum repo on the separate network.

If you hate manually packaging missing deps, you will love my megadeps patch for mock https://github.com/jfearn/mock

Basically install megadeps mock + patched cpanspec, set-up a RHEL/CentOS-5 mock root, and assuming your app has a sane spec file, just make the srpm and build that in the mock root with --megadeps, then wait for all the RPMs to be baked.

(and is frequently 5.8.8, which is outdated for a few necessary modules)

If it's core modules that need updating, then a lot of them can be made in to RPMs you just need to tweak the spec file so they get installed on a different path. The patched cpanspec linked to on my megadeps mock page automates this tweak.

Best part is when you upgrade to a newer RHEL/Centos you just set-up a RHEL/Centos-6 mock root and push your applications srpm in to that mock root, and megadeps will only package up the deps missing on that Perl :D

Of course if you actually need features of a newer Perl you are out of luck :)

oh! You could look in to using software collections, I believe there is an SCL for Perl 5.16 avaialle for RHEL-5. cpanspec would need some tweaks to spec file it emits, and the mock config would need to have the software collection repos added, but it shouldn't be a lot of work.

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

Maybe, if the two versions are compatible and you work hard enough, but

if you're compiling a new perl, forget about compatibility with the old version, get a newer version, at least 5.14

its easier just to use a portable perl like http://www.citrusperl.com/helpweb/installingcitrusperl.htm or http://dwimperl.com/linux.html

It would be nice to upgrade to the latest version of Perl, but as stated in my post, it would require us to manually rebuild and redistribute every module built with our system Perl, which is currently 5.10.1. So that option was sort of out of the question for us.

This is -- the worst part of using Linux / Unix. I've found Perl itself really easy to compile, but unless you have active internet connection to CPAN, very time consuming to get everything working right. If you get a nice packaged solution post it! I used a workstation with internet to compile everything and then got it moved, but it took lot of work to get it working and not an easy upgrade. I think an easier route to go is, assuming your machine has all necessary compilers, get the perl source and get a minicpan, though perlbrew might also work. In addition to the other suggestions maybe try this

bash# strace perl -e 'use DBI;' 2>&1 | grep -i DBI.so
stat64("/usr/local/lib/perl/5.18.2/auto/DBI/DBI.so", {st_mode=S_IFREG|
+0555, st_size=391823, ...}) = 0
open("/usr/local/lib/perl/5.18.2/auto/DBI/DBI.so", O_RDONLY|O_CLOEXEC)
+ = 5

bash# ldd -v /usr/local/lib/perl/5.18.2/auto/DBI/DBI.so
        linux-gate.so.1 =>  (0xb7727000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7539000)
        /lib/ld-linux.so.2 (0xb7728000)

        Version information:
        /usr/local/lib/perl/5.18.2/auto/DBI/DBI.so:
                libc.so.6 (GLIBC_2.3.4) => /lib/i386-linux-gnu/libc.so
+.6
                libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so
+.6
                libc.so.6 (GLIBC_2.4) => /lib/i386-linux-gnu/libc.so.6
                libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
                libc.so.6 (GLIBC_2.3) => /lib/i386-linux-gnu/libc.so.6
        /lib/i386-linux-gnu/libc.so.6:
                ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
[download]

Maybe that will shed some light on what is going on. You might have to track down all the .so files to make sure they are in the right place. Possibly you need to symlink a .so from somewhere else, or possibly someone else has symlinked a different version. As you can probably already tell, all in the weeds from here.

If you get a nice packaged solution post it!

Hey, I just updated my post above with the issue. It turns out matching the ./Configure flags to the system Perl was indeed the solution. The problem was that I was improperly testing the new build with a script that was pointing to an older, faulty build of Perl. Pointing the script to the new build with all of the ./Configure flags properly done corrected all of the issues.

Also, I appreciate the sympathy for lack of Internet. Lots of people simply reply "That's a dumb solution, why aren't you doing this and this instead" without taking into consideration the limitations that the programmer is forced to deal with as part of the job.

You could create a local cpan mirror.

It is possible your new build is using DBI but not finding some other required module or shared library, such as the DBD module?

You could use ldd path/to/DBI.so to see what is not being found for linking, which may give you a hint about where to focus your debugging work.