| Subject: | Failure to load binary modules found via PERL5LIB for tests on Fedora Core using -T |
If a binary module is located via PERL5LIB, then tests using the perl
which ships with Fedora Core (4,5,6,8) of other modules which use the
binary module and which use the -T flag will fail. This used to work
on T::H 2.64.
For this example, the module being tested is Decision::Depends (on
CPAN), which depends on Clone, which is a binary module.
In my environment, Clone is installed in directory which isn't part of
the standard Perl search path, and thus requires a PERL5LIB setting
for Perl to find it when installing modules which depend upon it.
Decision::Depends has a test script (t/00-load.t) which begins with
#!perl -T
This would ordinarily shut off utilization of PERL5LIB, but, from what
I deduce, T::H tries to work around this by passing the directories to
perl using -I. For some reason the perl shipped with Fedora Core (4-8
as far as I can tell) does not perform the same sort of platform
specific directory unfolding on directories passed to it with -I as it
does with those passed via PERL5LIB. (The Perls shipped with Debian Sarge &
Etch, as well as some local Perls compiled for Solaris do, so I'm
inclined to believe that Fedora patched their Perl).
For example, here are the salient bits of @INC output by perl -V when
passed the local Perl lib directory via PERL5LIB and -I:
% env PERL5LIB=/proj/axaf/ots/x86_64-linux_RHFC-5/lib/perl /usr/bin/perl
-V | grep ots
PERL5LIB="/proj/axaf/ots/x86_64-linux_RHFC-5/lib/perl"
/proj/axaf/ots/x86_64-linux_RHFC-5/lib/perl/5.8.8/x86_64-linux-thread-multi
/proj/axaf/ots/x86_64-linux_RHFC-5/lib/perl/5.8.8
/proj/axaf/ots/x86_64-linux_RHFC-5/lib/perl
% /usr/bin/perl -I/proj/axaf/ots/x86_64-linux_RHFC-5/lib/perl -V | grep ots
/proj/axaf/ots/x86_64-linux_RHFC-5/lib/perl
When T::H 2.64 invokes perl to run the tests, it passes the platform
specific directories on via -I, while T::H 3.12 does not. Hence the
test passes under 2.64 but fails under 3.12.
I'm not sure that I would call this a bug in T::H, as it's Fedora's
Perl which is causing this behavior. I'm not sure what your policy is
on supporting patched Perl's, but since it seems T::H once worked
around their foibles, I'm hoping it can be made to do so again.
Thanks for your work,
Diab