Bug #59499 for Module-Build: Many packages' Build.PL fails on perl5.10.0 with newer external version.pm

Sun Jul 18 02:47:08 2010 dmacks [...] netspace.org - Ticket created

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>

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

Sun Jul 18 13:36:21 2010 enobacon [...] gmail.com - Correspondence added

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>

# 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

Sun Jul 18 13:36:22 2010 The RT System itself - Status changed from 'new' to 'open'

Mon Jul 19 12:40:32 2010 dmacks [...] netspace.org - Correspondence added

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>

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.

Mon Jul 19 13:04:10 2010 enobacon [...] gmail.com - Correspondence added

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>

# 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

Mon Jul 26 23:45:09 2010 dagolden [...] cpan.org - Severity Normal added

Sun Dec 05 21:35:40 2010 dagolden [...] cpan.org - Correspondence added

Patched in the repo to warn and delete %INC entries

Sun Dec 05 21:35:42 2010 dagolden [...] cpan.org - Status changed from 'open' to 'patched'

Thu Jan 27 12:21:43 2011 dagolden [...] cpan.org - Correspondence added

Now that there has been a stable Module::Build release, I'm marking this "patched" issue as "resolved".

Thu Jan 27 12:21:44 2011 The RT System itself - Status changed from 'patched' to 'open'

Thu Jan 27 12:21:44 2011 dagolden [...] cpan.org - Status changed from 'open' to 'resolved'