Re^5: FindBin works different on Fedora Core 2?

Let's nail down some variables, here.

So far, I know two things -- one, you see the described behavior on your installations of FC1 and FC2. Two, I can reproduce the behavior on pre-FC1 (Shrike -- RH 9) and FC2. Looking at the module progressions -- not merely the perl progressions -- I can see many potentially relevant changes within the modules involved.

So. Let's nail down what code is running in each of your instances. It's perl 5.8.3 in both cases, as you say -- just to be sure, let's verify that. Ensure that each executable is the version you think it is.

Second, check your %INC hash. There could be local versions of these modules that are of a different version than the default shipped with perl 5.8.3.

Third -- and this is not likely but possible -- check that your perls are actually using version numbering on their system library directories (which should be the case by default, and should be the case with FC*, but if you've been doing regular package updates on them you will notice different perl version numbers down in /usr/lib/perl5). In any case, ensuring the perl executable version and the contents of %INC will flush this out as well.

If none of these appear to be running the newer code, which we know to exhibit the behavior you describe (as opposed to an earlier version of FC1 with no package updates, perhaps, but certainly the version of redhat just prior to FC1), then I will join you in being stumped.

Cheers,
Matt

Comment on Re^5: FindBin works different on Fedora Core 2?

Replies are listed 'Best First'.
Re^6: FindBin works different on Fedora Core 2? by samtregar (Abbot) on Jun 08, 2004 at 16:58 UTC
It's perl 5.8.3 in both cases, as you say -- just to be sure, let's verify that. Ensure that each executable is the version you think it is Verified. Both return 5.8.3 from 'perl -v'. However, the one on Fedora2 was built for i386-linux-thread-multi and the one on Fedora1 was build for i686-linux. I don't know why that would effect FindBin... Second, check your %INC hash. Done. Both %INC hashes are identical. Both scripts load the same modules from the same places, all within the 5.8.3 base module tree. Third -- and this is not likely but possible -- check that your perls are actually using version numbering on their system library directories Checked. Both are using 5.8.3 in their module paths. then I will join you in being stumped. Welcome to the club. I guess I'll just fix it and move on... I've got a nasty seg-fault to track down anyway. -sam	[reply]
Re^7: FindBin works different on Fedora Core 2? by mojotoad (Monsignor) on Jun 08, 2004 at 17:10 UTC
Verified. Both return 5.8.3 from 'perl -v'. However, the one on Fedora2 was built for i386-linux-thread-multi and the one on Fedora1 was build for i686-linux. I don't know why that would effect FindBin... I really think this has to do with the `abs_path()` implementation in Cwd.pm. Much of Cwd, including the `abs_path()` functionality, is written as XS and therefore lives down in arch-specific directories. Somehow the versions in each of your arch directories differ. Finally, in the Changes file, I note the following (I don't know if it's pertinent to your situation): `2.15 Fri Jan 16 08:09:44 CST 2004 + - Fixed a problem on static perl builds - while creating Makefile.aperl, it was loading a mismatched version of Cwd from blib/ .` [download] shrug Matt Update: I could be barking up the wrong tree here. In the versions I've been playing with, the following statements are in FindBin.pm: `FindBin.pm version 1.43 # Get absolute paths to directories $Bin = abs_path($Bin) if($Bin); $RealBin = abs_path($RealBin) if($RealBin);` [download] `FindBin.pm version 1.44 # Get absolute paths to directories $Bin = abs_path($Bin) unless (!$Bin \|\| File::Spec->file_na +me_is_absolute($Bin)); $RealBin = abs_path($RealBin) unless (!$RealBin \|\| File::Spec->fi +le_name_is_absolute($RealBin));` [download] In the first case, `abs_path()` is being invoked, whereas in the second case, it is not. The conditionals have changed.	[reply] [d/l] [select]