Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 59499
Status: resolved
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: dmacks [...] netspace.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Many packages' Build.PL fails on perl5.10.0 with newer external version.pm
Date: Sun, 18 Jul 2010 02:46:56 -0400
To: bug-Module-Build [...] rt.cpan.org
From: "Daniel Macks" <dmacks [...] netspace.org>
Download (untitled) / with headers
text/plain 2.5k
Not sure if this is a regression in version.pm or a new strictness there that Module::Build needs to compensate, but anyway...   OS X 10.6, apple-supplied perl5.10.0, fink-supplied Module::Build (module-build-pm5100-1:0.36.07-2) which drags along version (version-pm5100-1:0.82-1). Trying to build Params::Validate (0.95) according to the fink recipe fails:   perl5.10.0 Build.PL --install_path arch=/sw/build.build/root-params-validate-pm5100-0.95-1/sw/lib/perl5/5.10.0/darwin-thread-multi-2level --install_path bin=/sw/build.build/root-params-validate-pm5100-0.95-1/sw/bin --install_path bindoc=/sw/build.build/root-params-validate-pm5100-0.95-1/sw/lib/perl5/5.10.0/man/man1 --install_path lib=/sw/build.build/root-params-validate-pm5100-0.95-1/sw/lib/perl5/5.10.0 --install_path libdoc=/sw/build.build/root-params-validate-pm5100-0.95-1/sw/lib/perl5/5.10.0/man/man3 --install_path script=/sw/build.build/root-params-validate-pm5100-0.95-1/sw/bin Modification of non-creatable hash value attempted, subscript "version.pm" at /sw/lib/perl5/5.10.0/Module/Build/Version.pm line 34, <DATA> line 642. Compilation failed in require at /sw/lib/perl5/5.10.0/Module/Build/ModuleInfo.pm line 16, <DATA> line 642. BEGIN failed--compilation aborted at /sw/lib/perl5/5.10.0/Module/Build/ModuleInfo.pm line 16, <DATA> line 642. Compilation failed in require at /sw/lib/perl5/5.10.0/Module/Build/Base.pm line 23, <DATA> line 642. BEGIN failed--compilation aborted at /sw/lib/perl5/5.10.0/Module/Build/Base.pm line 23, <DATA> line 642. Compilation failed in require at /sw/lib/perl5/5.10.0/Module/Build.pm line 14, <DATA> line 642. BEGIN failed--compilation aborted at /sw/lib/perl5/5.10.0/Module/Build.pm line 14, <DATA> line 642. Compilation failed in require at Build.PL line 6, <DATA> line 642. BEGIN failed--compilation aborted at Build.PL line 6, <DATA> line 642.     I can reproduce this result from the command-line using *any* invocation of Build.PL ('perl5.10.0 Build.PL', 'perl5.10.0 Build.PL --help', etc.). If I uninstall the fink "version" package (forced override of the module-build dependency), Build.PL works fine. The version module is dual-lifed, so the trigger appears to be upgrading/overlaying apple's version-0.74 with fink's version-0.82. My fink is configured for i386 (32bit single-arch).   Googling for that error message, I see it reported back in May on the FreeBSD mailing list, so it doesn't seem like specifically a mac or fink issue. http://www.mail-archive.com/freebsd-ports@freebsd.org/msg27477.html   dan -- Daniel Macks dmacks@netspace.org
Subject: Re: [rt.cpan.org #59499] Many packages' Build.PL fails on perl5.10.0 with newer external version.pm
Date: Sun, 18 Jul 2010 10:36:05 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
Download (untitled) / with headers
text/plain 432b
# from dmacks@netspace.org via RT # on Saturday 17 July 2010 23:47: Show quoted text
>Modification of non-creatable hash value attempted, subscript > "version.pm" at /sw/lib/perl5/5.10.0/Module/Build/Version.pm line 34
Please let us know what the .pm says on line 34 there. It looks like it should be: $INC{'version.pm'} = 'inside Module::Build::Version'; If so, what about `perl -e '$INC{"foo.pm"} = "something something"'` ? Thanks, Eric
Subject: Re: [rt.cpan.org #59499] Many packages' Build.PL fails on perl5.10.0 with newer external version.pm
Date: Mon, 19 Jul 2010 12:40:21 -0400
To: bug-Module-Build [...] rt.cpan.org
From: "Daniel Macks" <dmacks [...] netspace.org>
Download (untitled) / with headers
text/plain 2.2k
Show quoted text
> Please let us know what the .pm says on line 34 there. It looks like it > should be: > > $INC{'version.pm'} = 'inside Module::Build::Version';
  That is correct.   Show quoted text
> If so, what about `perl -e '$INC{"foo.pm"} = "something something"'` ?
  Works without error (even with -Mstrict) and the new value correctly replaces the old. Also works with the actual 'version.pm' key when done manually.   Hacking on version and M::B::Version, one way to cause the same symptom is to have the 'version' module exist but fail to load its internally-required other modules (in my case, binary/architecture mismatch for version::vpp). We're in the if($@) block for when 'eval "use version $VERSION"' fails. In this situation, $INC{"version.pm"} exists as undef (exists because 'use version' at least started to load it, but not defined to the path because the load failed partway through?). "exists but undef" is what leads to my error message. If no version ('use version' completely fails to even start loading it), there is no key in %INC, so not an error to write to it. It's gotta be something in the deep magic of %INC and module-loading, because it's not an error to set-to-undef and then set-to-arbitrary-string other values in that hash.   Here's my simple test-case:   perl5.10.0 -Mstrict -e 'eval {require foo};exists $INC{"foo.pm"} ? (defined $INC{"foo.pm"} ? print $INC{"foo.pm"},"\n" : print "(undef)\n"): print "(no such)\n";$INC{"foo.pm"}="wocka"'   == foo.pm == [file doesn't exist] == result: (no such)   == foo.pm == package foo; 1; == result: foo.pm   == foo.pm == package foo; 0; == result: (no such)   == foo.pm == package foo; use bar_does_not_exist; == result: (undef) Modification of non-creatable hash value attempted, subscript "foo.pm" at -e line 1.     So the eval can fail for many reasons other than "version.pm isn't present", and at least one of those can't be cleanly compensated-for by simply overloading and setting $INC for it (the current fallback where my original error arose). Should my fail-to-load state (udef) be treated as a fatal error in M::B::Version? Having this value does *not* prevent future "require foo" from trying to (re)load foo.pm, whereas in the (no such) states when $INC then gets set to something arbitrarily defined, future "require foo.pm" is a no-op.  
Subject: Re: [rt.cpan.org #59499] Many packages' Build.PL fails on perl5.10.0 with newer external version.pm
Date: Mon, 19 Jul 2010 10:03:57 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Eric Wilhelm <enobacon [...] gmail.com>
Download (untitled) / with headers
text/plain 797b
# from dmacks@netspace.org via RT # on Monday 19 July 2010 09:40: Show quoted text
>So the eval can fail for many reasons other than "version.pm isn't >present", and at least one of those can't be cleanly compensated-for > by simply overloading and setting $INC for it (the current fallback > where my original error arose). Should my fail-to-load state (undef) > be treated as a fatal error in M::B::Version?
Yes, we probably should explode noisily (or at least warn) about things being broken. eval "use version $VERSION"; if ($@) { # can't locate version files, use our own die $@ unless $@ =~ m/Can't locate version\.pm in \@INC/; ... It might also be possible to delete($INC{'version.pm'}) before trying to assign it, in which case we could just warn() instead of die() above. Thanks, Eric
Patched in the repo to warn and delete %INC entries
Download (untitled) / with headers
text/plain 103b
Now that there has been a stable Module::Build release, I'm marking this "patched" issue as "resolved".


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.