You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@perl.apache.org by William McKee <wi...@knowmad.com> on 2005/02/10 19:00:03 UTC
Import errors in TestConfig.pm under Win32
Hi folks,
Hopefully I'm on the right mailing list for this discussion. I have the
misfortunate of needing to get a package I've written to work under
Win32 (2003 Server and XP). While doing so, I've come across some
problems in the A::T module. Specifically, the lib->import($top_dir)
line in TestConfig.pm is failing with the following error:
"C:\work\bug-reporting-skeleton-mp2" is not exported by the lib module
Can't continue after import errors at
C:/Perl/site/lib/Apache/TestConfig.pm line 223
Using Geoff's bug reporting framework, I tracked the error down to the
Time::Piece package. If I use this package, I get the error. If I don't,
there's no problem. I was seeing this issue under WinXP with Apache
2.0.48, ActiveState Perl 5.8.3 and mod_perl 1.99_13. I do not see the
problem under Linux with Apache 1.3.31, Perl 5.8.6 and mp 1.29. I do not
have Apache2/mp2 on Linux so have not tested that combination.
Seeing how old my packages were (I don't use this laptop much), I
subsequently upgraded to Apache 2.0.52, ActiveState Perl 5.8.6 and
mod_perl 1.9921. Unfortunately, the same error still occurred and a new
one began (see follow-up message).
My example code can be retrieved from my website[1].
Thanks,
William
[1]
http://knowmad.com/~william/bug-reporting-skeleton-mp2_WLM20040210T125200.zip
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Import errors in TestConfig.pm under Win32
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
>>Sounds OK?
>
>
> This sounds good to me, Stas. I agree that we should limit the
> workaround added to A::T, esp. if those are getting fixed in future
> versions of Perl.
>
> My simplistic workaround is to add a 'use lib;' line in my test code
> right after I call in the module which uses UNIVERSAL.
Excellent :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Import errors in TestConfig.pm under Win32
Posted by William McKee <wi...@knowmad.com>.
> Sounds OK?
This sounds good to me, Stas. I agree that we should limit the
workaround added to A::T, esp. if those are getting fixed in future
versions of Perl.
My simplistic workaround is to add a 'use lib;' line in my test code
right after I call in the module which uses UNIVERSAL.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Import errors in TestConfig.pm under Win32
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Thu, Feb 10, 2005 at 06:32:30PM -0500, Stas Bekman wrote:
>
>>That most likely means that someone redefines sub lib::import. Could be
>>Time::Piece or something else used by that module. It's their fault, not
>>A-T's one. You could easily verify that by adding something like:
>
>
> I love hanging out with you guys; always something new to learn. Thanks
> for the hints. Unfortunately the $SIG{__DIE__} trick didn't work.
> Perhaps that's due to the fact that this bug lies within the UNIVERSAL
> module. Basically, Time::Piece has the following line which is causing
> the problems:
>
> use UNIVERSAL qw(isa);
>
>>>From what I read about UNIVERSAL in its source, it causes the import
> method to be redefined. I was able to create a script that reproduces
> the error. The error happens under Linux as well. This begs the question
> as to why A::T works without error on Linux but not on Windows.
>
> Further testing has shown that order is important. If I place a 'use
> lib' line *after* the use UNIVERSAL (or any other module which uses
> UNIVERSAL), all is well. However, I still don't get the reason why these
> tests would fail under Windows but work under Linux. There must be
> something different about my Perl environment between the two.
>
> Now, since we know that using the UNIVERSAL module is not uncommon,
> should A::T take measures to defend against lib->import getting
> redefined? Adding a 'use lib;' line just before the call to
> lib->import($top_dir) works for me under WinXP and does not generate
> redefine warnings.
Since it's not A-T's fault that someone has redefined the lib::import, I
don't think it's for us to fix it. At least for now I believe it's the
best that you apply the workaround in your code. i.e. after you load the
module that redefines lib::import force the reload of lib.pm which should
restore it back. alternatively you could remember the original sub and
restore it w/o reloading lib.pm:
my $orig_sub = *lib::import{CODE};
require ModuleBreakinglibpm;
*lib::import = $orig_sub;
notice that it uses 'require' and not 'use'.
if later on we start getting more similar reports we will consider adding
a workaround in A-T.
Sounds OK?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Import errors in TestConfig.pm under Win32
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
[...]
> Yes, drop the use lib which is more in line which how A::TestConfig is
> written (it nevers calls use lib). Apparently, calling 'use lib' fixes
> the import function and has nothing to do with the order it's called in
> as I had surmised in an earlier email.
Hehe, it's so silly of us :) I've committed your proposed fix. Thank you,
William.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Import errors in TestConfig.pm under Win32
Posted by William McKee <wi...@knowmad.com>.
On Sat, Feb 12, 2005 at 12:10:26PM -0500, Stas Bekman wrote:
> >Given that A::T is calling the undocumented method lib->import directly,
>
> why undocumented?
In the sense that it isn't mentioned in the POD.
> the only difference is that we don't have the BEGIN block. So it happens
> at run time and not compile time.
I see. Neat trick.
> It's not the same because lib::import does more than that (removing dups,
> inserting arch-specific dirs, etc.). Though in this particular case one
> could argue that your solution above is almost an equivalent.
OK.
> I'd still suggest to first write a simple standalone case that
> demonstrates the problem and see if p5p has anything insightful to say
> about it. We can work out the test case here.
That's what I was playing with this morning when I realized the fix
doesn't really cure the bug I'm seeing.
> For example this:
>
> perl -wle 'use lib "/tmp"; use UNIVERSAL qw(isa); \
> lib->import("/tmp/foo"); print join "\n", @INC'
>
> seems to work just fine. Can you break it?
Yes, drop the use lib which is more in line which how A::TestConfig is
written (it nevers calls use lib). Apparently, calling 'use lib' fixes
the import function and has nothing to do with the order it's called in
as I had surmised in an earlier email.
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Import errors in TestConfig.pm under Win32
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> Stas,
>
> I ran some tests before making this request to p5p. In doing so, it
> turns out the cure is not much better than the bug; it really just
> side skirts the problem by doing an empty return (see the import method
> that's been added to UNIVERSAL.pm in bleadperl).
>
> We still are faced with the problem that importing UNIVERSAL is
> overwriting/overloading the import subroutine in lib (and apparently all other
> loaded modules). Furthermore, from the notes in UNIVERSAL, this behavior
> can't be fixed. This leads me to want to avoid use UNIVERSAL in any of
> my code but I can't fix all the released modules.
>
> Given that A::T is calling the undocumented method lib->import directly,
why undocumented?
use lib LIST;
is the same as:
BEGIN {
require lib;
lib->import(LIST);
}
the only difference is that we don't have the BEGIN block. So it happens
at run time and not compile time.
> it seems it should work around this problem if tests import UNIVERSAL.
> Could line 223 in A::TestConfig be changed to the following:
>
> unshift(@INC, $topdir);
It's not the same because lib::import does more than that (removing dups,
inserting arch-specific dirs, etc.). Though in this particular case one
could argue that your solution above is almost an equivalent.
I'd still suggest to first write a simple standalone case that
demonstrates the problem and see if p5p has anything insightful to say
about it. We can work out the test case here.
For example this:
perl -wle 'use lib "/tmp"; use UNIVERSAL qw(isa); \
lib->import("/tmp/foo"); print join "\n", @INC'
seems to work just fine. Can you break it?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Import errors in TestConfig.pm under Win32
Posted by William McKee <wi...@knowmad.com>.
Stas,
I ran some tests before making this request to p5p. In doing so, it
turns out the cure is not much better than the bug; it really just
side skirts the problem by doing an empty return (see the import method
that's been added to UNIVERSAL.pm in bleadperl).
We still are faced with the problem that importing UNIVERSAL is
overwriting/overloading the import subroutine in lib (and apparently all other
loaded modules). Furthermore, from the notes in UNIVERSAL, this behavior
can't be fixed. This leads me to want to avoid use UNIVERSAL in any of
my code but I can't fix all the released modules.
Given that A::T is calling the undocumented method lib->import directly,
it seems it should work around this problem if tests import UNIVERSAL.
Could line 223 in A::TestConfig be changed to the following:
unshift(@INC, $topdir);
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Import errors in TestConfig.pm under Win32
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> On Fri, Feb 11, 2005 at 12:24:17PM -0500, Stas Bekman wrote:
>
>>So contact p5p and ask to put that into the maint line (5.8.x).
>
>
> Dumb question. How would I do this? Subscribe to the list and send a
> message? Submit a bug report at http://rt.perl.org/perlbug/?
As this bug has already been fixed, I think just posting directly to p5p
and explaining that the bug fix that you've quoted in the earlier message
is important for the maint line and asking Nicholas (the current maint
pumpkin) whether he can consider merging it into the the maint line. no
need for submitting a real bug report. e.g. with a subject like:
Subject: please merge the patch for bug XXXXX into the maint branch
(replacing XXXX with the rt bug id)
I'm not sure if you need to be subscribed to p5p in order to post, so the
simplest is to subscribe :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Import errors in TestConfig.pm under Win32
Posted by William McKee <wi...@knowmad.com>.
On Fri, Feb 11, 2005 at 12:24:17PM -0500, Stas Bekman wrote:
> So contact p5p and ask to put that into the maint line (5.8.x).
Dumb question. How would I do this? Subscribe to the list and send a
message? Submit a bug report at http://rt.perl.org/perlbug/?
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Import errors in TestConfig.pm under Win32
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> While doing a bit more beefing up on the problem with UNIVERSAL, I came
> across a posting by Schwern[1] which contains a patch would potentially
> fix this problem. Unfortunately, it doesn't look to have made it into
> any released code but is part of bleadperl.
>
>
> William
>
> [1] http://www.mail-archive.com/perl5-porters@perl.org/msg69701.html
So contact p5p and ask to put that into the maint line (5.8.x).
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Import errors in TestConfig.pm under Win32
Posted by William McKee <wi...@knowmad.com>.
While doing a bit more beefing up on the problem with UNIVERSAL, I came
across a posting by Schwern[1] which contains a patch would potentially
fix this problem. Unfortunately, it doesn't look to have made it into
any released code but is part of bleadperl.
William
[1] http://www.mail-archive.com/perl5-porters@perl.org/msg69701.html
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Import errors in TestConfig.pm under Win32
Posted by William McKee <wi...@knowmad.com>.
On Thu, Feb 10, 2005 at 06:32:30PM -0500, Stas Bekman wrote:
> That most likely means that someone redefines sub lib::import. Could be
> Time::Piece or something else used by that module. It's their fault, not
> A-T's one. You could easily verify that by adding something like:
I love hanging out with you guys; always something new to learn. Thanks
for the hints. Unfortunately the $SIG{__DIE__} trick didn't work.
Perhaps that's due to the fact that this bug lies within the UNIVERSAL
module. Basically, Time::Piece has the following line which is causing
the problems:
use UNIVERSAL qw(isa);
>From what I read about UNIVERSAL in its source, it causes the import
method to be redefined. I was able to create a script that reproduces
the error. The error happens under Linux as well. This begs the question
as to why A::T works without error on Linux but not on Windows.
Further testing has shown that order is important. If I place a 'use
lib' line *after* the use UNIVERSAL (or any other module which uses
UNIVERSAL), all is well. However, I still don't get the reason why these
tests would fail under Windows but work under Linux. There must be
something different about my Perl environment between the two.
Now, since we know that using the UNIVERSAL module is not uncommon,
should A::T take measures to defend against lib->import getting
redefined? Adding a 'use lib;' line just before the call to
lib->import($top_dir) works for me under WinXP and does not generate
redefine warnings.
Cheers,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Import errors in TestConfig.pm under Win32
Posted by Stas Bekman <st...@stason.org>.
William McKee wrote:
> Hi folks,
>
> Hopefully I'm on the right mailing list for this discussion. I have the
> misfortunate of needing to get a package I've written to work under
> Win32 (2003 Server and XP). While doing so, I've come across some
> problems in the A::T module. Specifically, the lib->import($top_dir)
> line in TestConfig.pm is failing with the following error:
>
> "C:\work\bug-reporting-skeleton-mp2" is not exported by the lib module
> Can't continue after import errors at
> C:/Perl/site/lib/Apache/TestConfig.pm line 223
>
> Using Geoff's bug reporting framework, I tracked the error down to the
> Time::Piece package. If I use this package, I get the error. If I don't,
> there's no problem. I was seeing this issue under WinXP with Apache
That most likely means that someone redefines sub lib::import. Could be
Time::Piece or something else used by that module. It's their fault, not
A-T's one. You could easily verify that by adding something like:
no warnings 'redefine';
do "lib.pm";
before line 223, which will override it again.
To debug the problem, add:
use Carp;
$SIG{__DIE__} = \&Carp::confess;
in which case you will see who generates that error message.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com