Skip Menu |
 

This queue is for tickets about the Test-Harness CPAN distribution.

Report information
The Basics
Id: 37029
Status: resolved
Priority: 0/
Queue: Test-Harness

People
Owner: Nobody in particular
Requestors: djerius [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 3.12
Fixed in: (no value)



Subject: Failure to load binary modules found via PERL5LIB for tests on Fedora Core using -T
Download (untitled) / with headers
text/plain 2.1k
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
From: skasal [...] redhat.com
Download (untitled) / with headers
text/plain 1.2k
Hello, On Mon Jun 23 15:26:49 2008, DJERIUS wrote: Show quoted text
> [...] 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 & Show quoted text
> Etch, as well as some local Perls compiled for Solaris do, so I'm > inclined to believe that Fedora patched their Perl).
indeed, this looks like a bug in perl build in Fedora Core 4 -- Fedora 8. But I was not able to reproduce the bug on Fedora 9, nor on Fedora development (rawhide), which both contain perl-5.10.0 Show quoted text
> 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.
Of the products you mention, Fedora 8 is the only which is still supported. If you would like to see this bug fixed there, please file a bug to bugzilla.redhat.com, Release Fedora 8, component perl. The possibility of a fixed build will be discussed there. Unfortunately, anything which is a bug fix for someone, is a break of backward compatibility for someone else.
Subject: Re: [rt.cpan.org #37029] Failure to load binary modules found via PERL5LIB for tests on Fedora Core using -T
Date: Tue, 1 Jul 2008 16:49:16 +0100
To: bug-Test-Harness [...] rt.cpan.org
From: Andy Armstrong <andy [...] hexten.net>
Download (untitled) / with headers
text/plain 816b
On 1 Jul 2008, at 16:30, Stepan Kasal via RT wrote: Show quoted text
>> [...] 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).
> > indeed, this looks like a bug in perl build in Fedora Core 4 -- > Fedora 8. > > But I was not able to reproduce the bug on Fedora 9, nor on Fedora > development (rawhide), which both contain perl-5.10.0
The RH/FC/Centos patch to Perl's @INC handling has already acquired 'notorious' status around here :) -- Andy Armstrong, Hexten
From: skasal [...] redhat.com
Download (untitled) / with headers
text/plain 506b
On Tue Jul 01 11:49:36 2008, ANDYA wrote: Show quoted text
> The RH/FC/Centos patch to Perl's @INC handling has already acquired > 'notorious' status around here :)
We are always happy whenever the accumulated cruft of patches and other build hacks is reduced. For perl, this happened during the switch to perl-5.10, in release Fedora 9. We are glad to hear this is appreciated. In case you encounter other Fedora-specific problem in perl, do not hesitate to file them to bugzilla.redhat.com, so that we can fix them.
CC: djerius [...] cpan.org
Subject: Re: [rt.cpan.org #37029] Failure to load binary modules found via PERL5LIB for tests on Fedora Core using -T
Date: Fri, 11 Jul 2008 15:15:15 -0400
To: bug-Test-Harness [...] rt.cpan.org
From: Diab Jerius <dj [...] head.cfa.harvard.edu>
On Tue, 2008-07-01 at 11:30 -0400, Stepan Kasal via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=37029 > > > Hello, > > On Mon Jun 23 15:26:49 2008, DJERIUS wrote:
> > [...] 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).
> > indeed, this looks like a bug in perl build in Fedora Core 4 -- Fedora 8. > > But I was not able to reproduce the bug on Fedora 9, nor on Fedora > development (rawhide), which both contain perl-5.10.0 >
> > 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.
> > Of the products you mention, Fedora 8 is the only which is still > supported. If you would like to see this bug fixed there, please file a > bug to bugzilla.redhat.com, Release Fedora 8, component perl. > The possibility of a fixed build will be discussed there.
Show quoted text
> Unfortunately, anything which is a bug fix for someone, is a break of > backward compatibility for someone else.
That's my fear; at this late stage in Fedora 8's lifetime, I doubt anyone wants to change things. I sure as heck wouldn't want that to happen. In any case, I have to support Fedora 4-8 in house, so was hoping for a "fix" to T::H. I'm not sure how widespread the use of -T is in tests on CPAN, or how often Fedora users go beyond the Perl modules shipped with their distribution, but if anyone of them decides to upgrade T::H there may be more reports like mine. I'll work around the issue by flooding PERL5LIB with the appropriate entries before building on Fedora < 9. Thanks.
Thanks :)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.