in reply to Devel::CheckLib problem

At line 333 of CheckLib.pm, swap:

sub _findcc { my @flags = grep { length } map { quotewords('\s+', 0, $_ || ()) } @Config{qw(ccflags ldflags)};

For:

sub _findcc { my @flags = @Config{qw(ccflags ldflags)}; @flags = grep { length } map { quotewords('\s+', 0, $_ || ()) } @f +lags;

And the module will load.

And no, I have no idea why that should affect a fix, but it seems to on my 64-bit AS1007 setup.

All I can add at this point is that with the original, when it gets to line 13 of Config_Heavy.pl it goes tits up:

... >> [0] C:/Perl64/lib/Config.pm : 76: die "&Config::AUTOLOA +D failed on $Config::AUTOLOAD"; >> [0] C:/Perl64/lib/Config_heavy.pl : 13: die $@ if $@ && +$@ !~ /^Can't locate ActivePerl\/Config\.pm/; &Config::AUTOLOAD failed on Config::launcher at C:/Perl64/lib/Config.p +m line 76. BEGIN failed--compilation aborted at C:/Perl64/lib/ActivePerl/Config.p +m line 4. Compilation failed in require at C:/Perl64/lib/Config_heavy.pl line 11 +. BEGIN failed--compilation aborted at C:/Perl64/lib/Config_heavy.pl lin +e 15. Compilation failed in require at C:/Perl64/lib/Config.pm line 74. >> [0] C:/Perl64/lib/File/Temp.pm : 870: local($., $@, $!, $^E +, $?); >> [0] C:/Perl64/lib/File/Temp.pm : 871: cleanup(); >> [0] C:/Perl64/lib/File/Temp.pm : 877: if (!$KEEP_ALL) { >> [0] C:/Perl64/lib/File/Temp.pm : 880: @{ $fi +les_to_unlink{$$} } : () ); >> [0] C:/Perl64/lib/File/Temp.pm : 881: foreach my $file (@ +files) { >> [0] C:/Perl64/lib/File/Temp.pm : 895: @{ $dir +s_to_unlink{$$} } : () ); >> [0] C:/Perl64/lib/File/Temp.pm : 896: foreach my $dir (@d +irs) { >> [0] C:/Perl64/lib/File/Temp.pm : 908: @{ $files_to_unlink +{$$} } = () >> [0] C:/Perl64/lib/File/Temp.pm : 910: @{ $dirs_to_unlink{ +$$} } = ()

But with the change, that line runs fine:

... >> [0] C:/Perl64/lib/Config_heavy.pl : 13: die $@ if $@ && +$@ !~ /^Can't locate ActivePerl\/Config\.pm/; >> [0] C:/Perl64/lib/Config_heavy.pl : 19: our $summary = <<'!END!'; >> [0] C:/Perl64/lib/Config_heavy.pl : 52: my $summary_expanded; >> [0] C:/Perl64/lib/Config_heavy.pl : 73: local *_ = \my $a; >> [0] C:/Perl64/lib/Config_heavy.pl : 74: $_ = <<'!END!'; >> [0] C:/Perl64/lib/Config_heavy.pl : 1155: my $i = 0; ...

However, even with the fix, the suggested test line produces no output. I'm not sure if that is good or bad?, but I guess it is at least progress:

C:\test>perl -MDevel::CheckLib -e1 C:\test>

Let me know If I can try anything else to help you solve this.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Devel::CheckLib problem
by syphilis (Archbishop) on Dec 09, 2010 at 15:24 UTC
    Between your suggested change to _findcc() and Chris Marshall's suggestion, I've arrived at:
    sub _findcc { my @flags = @Config{qw(ccflags ldflags)}; @flags = grep { length } map { quotewords('\s+', 1,$_) } @flags;
    That works pretty well. There's now just the one failing test in the Devel::CheckLib test suite:
    t/multi-word-compiler.........Subroutine STORE redefined at C:/_32/ap1 +005/lib/Config_heavy.pl line 1177. Set up gcc environment - 3.4.5 (mingw-vista special r3) %Config::Config is read-only # Looks like your test died before it could output anything. t/multi-word-compiler.........dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay
    Looks like STORE gets redefined to a form that we don't want. I think the error is in response to the following line in t/multi-word-compiler.t:
    $Config{cc} = "$^X $Config{cc}";
    Needless to say, 'perl -Mblib t/multi-word-compiler.t' passes the test :-))))
    C:\_32\comp\Devel-CheckLib-0.91>perl -Mblib t/multi-word-compiler.t 1..1 Set up gcc environment - 3.4.5 (mingw-vista special r3) ok 1 - Good multi-word compiler is OK
    Cheers,
    Rob

      I'd try replacing $Config{cc} = "$^X $Config{cc}"; with $Config{cc} = $^X . ' ' . $Config{cc};.

      That's based on nothing more than guesswork as I didn't actually download the whole package, just the .pm file. (You'd already said most of the tests failed:)

      I'm fascinated by the /blib thing. Does it work if you load some other inconsequential module; say bytes or less or maybe just strict?

      I've got this niggle in the back of my head. Something about adding coderefs to @INC or %INC, I forget the dtails. Maybe putting something (anything) in those stops some too-clever-by-half piece of code getting invoked?


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        I'd try replacing $Config{cc} = "$^X $Config{cc}"; with $Config{cc} = $^X . ' ' . $Config{cc};

        Doesn't help, unfortunately. It was also suggested I try making $Config{cc} local to that test script, but that changes nothing.

        Does it work if you load some other inconsequential module; say bytes or less or maybe just strict?

        Nup - has to be 'blib'. The script already loads strict.pm, and I did try out 'less' and 'bytes' ... to no avail. (There may of course be some module other than 'blib' that has the same effect.)

        I probably ought to take a look at blib and see what it's doing. Perhaps, therein, lies the clue.

        Cheers,
        Rob