Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've installed CentOS 6.3 (i386) recently.

It has two perl binary

/usr/bin/perl (v5.10.1)
/usr/local/appx/perl/bin/perl (v5.8.8)

My question: Is it possible to install some other funtinonality to that application using system wide perl & perl's module from that appx?

Like below:

./configue -prefix=/usrl/local/app_xyz -perl_lib_path=/usr/local/appx/perl/lib/5.8.8/

I've tried the above, I got error the following error:

RRD Perl Module -----------------**Not Found**

But that perl module RRDs.pm is available under the /usr/local/appx/lib/5.8.8 directory.

Also the configure script doesn't have ARG to map our appx perl binary path (/usr/local/appx/perl/bin/perl), it automatically picks the system wide perl as default.

share|improve this question
Assuming configure doesn't have an option for the path to Perl, maybe something like PATH="/usr/local/appx/perl/bin:$PATH" ./configure -prefix=… would work? – derobert Apr 29 '13 at 17:20
up vote 1 down vote accepted

Perl 5 minor versions are backward compatible, so a 5.8.8 module should work with a 5.10.1 perl (but there is an exception, see CAVEAT below). The include path (@INC) is configured in when perl is built, but @INC can be modified by individual programs, and globablly the content of the environment variable $PERL5LIB is prepended.

export PERL5LIB=/usr/local/appx/lib/5.8.8

However, there is a problem with this approach. Because $PERL5LIB is prepended to @INC, doing this will cause the 5.8.8 directory to take precedence when loading various standard modules. That's not desirable.

So, a less tidy but ultimately better idea is to just symlink /usr/local/appx/lib/5.8.8/RRD.pm (and/or the RRD directory, if there is one) into /usr/local/lib/perl5 or some other standard @INC directory. You can see those with:

perl -e 'print "$_\n" foreach @INC'

Note that there may be both a top level RRD.pm and a parallel RRD directory; if so you want to symlink both.


Some perl modules include parts that are compiled from C, and these may break. If RRD.pm does not use C, then you don't have to worry. If it does, you should copy it instead of symlinking it and rebuild; for that you need the source, which may or may not be there :(

share|improve this answer
I'm pretty sure that while Perl code is mostly backwards compatible, the C API is not. So any compiled XS code will not work. – derobert Apr 29 '13 at 15:17
I think the public C API (as presented in perlguts, etc) is backward compatible but I asked on #perl about this and you are correct -- changes to the internal API can result in binary incompatibility. Will add a note about this. – goldilocks Apr 29 '13 at 15:47
Thanks all finally got the solution through EXPORT – Ram S Jun 18 '13 at 5:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.