Perl versions conflict help

jujiro_eb has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,

I installed Oracle 10g on my Vista machine. Oracle installs a custom version of perl for its scripting needs. Note that Oracle's perl sets PERL5LIB variable.

A few days later I installed ActiveState (5.10) for my needs.

So, now when I do the following using ActiveState, I get an error:

C:\temp\ama>c:\perl\bin\perl -V
Perl lib version (v5.8.3) doesn't match executable version (v5.10.1) a
+t D:\oracl
e\product\10.2.0\db_1\perl\5.8.3\lib/MSWin32-x86-multi-thread/Config.p
+m line 32.

Compilation failed in require.
BEGIN failed--compilation aborted.
[download]

So, first question is why ActiveState is not able to find its own config.pm? If I unset PERL5LIB variable, the perl -V (above) works fine. I have this type of question, yet I am still mystified with the PERL5LIB variable, because libraries in PERL5LIB are still searched even when I run ActiveState perl with -I switch providing explicit path to all my libraries.

Can you please help demystify the PERL5LIB variable.

Thanks so much.

Ash

Comment on Perl versions conflict help Download Code

Replies are listed 'Best First'.
Re: Perl versions conflict help by zwon (Abbot) on Nov 13, 2009 at 19:02 UTC
So, first question is why ActiveState is not able to find its own config.pm? Because by setting `PERL5LIB` variable you're explicitly asking it to start search libraries in specified directory. `-I` switch doesn't prevent from using PERL5LIB, though directory specified with `-I` is used first.	[reply] [d/l] [select]
Re^2: Perl versions conflict help by jujiro_eb (Sexton) on Nov 13, 2009 at 23:28 UTC
Hi Zwon, I totally get what you are saying. However, ELISHEVA writes in one of her threads with me, "Keeping every thing separate also saves you from a nightmare of version compatibility issues. You don't have to worry about your application breaking if other applications need older or newer versions of a module". To me, unsetting PERL5LIB is breaking someone else's application. I suppose there is no way around it. Ash	[reply]
Re^3: Perl versions conflict help by zwon (Abbot) on Nov 14, 2009 at 10:20 UTC
In this case you can set `PERL5LIB` on a per application basis.	[reply] [d/l]
Re^4: Perl versions conflict help by Anonymous Monk on Nov 14, 2009 at 10:27 UTC
Re: Perl versions conflict help by afoken (Chancellor) on Nov 14, 2009 at 10:41 UTC
I smell Oracle here. Oracle comes with its own Perl, but uses it rarely or even not at all. There are some very obsure perl scripts in the Oracle directories that you usually do not need. Removing the Oracle's Perl using the Universal Installer is possible, but due to some dependancies, the UI will also remove lots of other parts of Oracle. I've manually deleted the Perl directories that Oracle installed (`D:\oracle\product\10.2.0\db_1\perl\` in your case) several times, no Oracle installation broke, and "my" Perl (ActiveState's ActivePerl in the old days, Strawberry Perl today) just worked. From my experience with Perl on Windows, I strongly recommend NOT to have more than one Perl on a Windows machine. If you fear to break Oracle, use Oracles antique Perl. If you need a newer Perl, get rid of Oracle's Perl. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^2: Perl versions conflict help by Mr. Muskrat (Canon) on Nov 16, 2009 at 21:13 UTC
If you remove Oracle's version of Perl you may not know that you have broken something important until your data is hosed. Solution: Set the real PERL5LIB at the OS level for your users and override Oracle's PERL5LIB so that it can still find its own modules.	[reply]