syphilis has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
I've just rebuilt perls 5.8.0, 5.8.9, 5.10.0, 5.12.0 and 5.14.0 using the MinGW port of gcc-4.5.2 (on Windows Vista).

No problems with Math-GSL-0.26 except for 5.10.0 where the perl Build.PL step hammers me with:
C:\sisyphusion_hide\Math-GSL-0.26>perl build.pl Checking for GSL..Found GSL version 1.15 Checking if gcc supports "-Wall"...yes Checking if gcc supports "-Wno-unused-function"...yes Checking if gcc supports "-Wno-unused-value"...yes Checking if gcc supports "-Wno-unused-function"...yes Checking if gcc supports "-Wno-unused-variable"...yes Checking if gcc supports "-g"...yes The filename, directory name, or volume label syntax is incorrect. The filename, directory name, or volume label syntax is incorrect. The filename, directory name, or volume label syntax is incorrect. The filename, directory name, or volume label syntax is incorrect. The filename, directory name, or volume label syntax is incorrect. Can't locate the perl binary used to run this script in (C:\MinGW\perl +510\bin C: \MinGW\perl510\bin c:\Mingw\perl510\bin . C:\Gtk+\bin C:\Program Files +\Windows N T\Accessories C:\MinGW\bin C:\_32\dmake C:\Windows\system32 C:\Windows + C:\Window s\System32\Wbem C:\batch C:\_32\lzma C:\MinGW\perl510\bin C:\MinGW\msy +s\1.0\bin)
It's the GSLBuilder->new() call in the Build.PL script that makes everything go apeshit. Annoyingly, I can't even find where that new() sub is defined ... certainly can't find it in inc/GSLBuilder.pm.

Anyone know what might be going on ?

By some strange coincidence, many (but not all) of the modules that I've tried to install using CPAN.pm on this build of perl-5.10.0 are also getting screwed by the same absurd error.
Apart from the fact that I loathe both Module::Build and CPAN.pm, I don't know what the connection is.

Cheers,
Rob

Replies are listed 'Best First'.
Re: [Win32] Math::GSL on perl 5.10.0
by BrowserUk (Patriarch) on Nov 04, 2011 at 14:19 UTC

    I suspect this is a variation on an old cpan bug-bear of mine.

    Instead of just using the string 'perl' in the commands it is going to run and allowing the appropriate executable to be found by the system shell and perl, they get all premature optimise-y about it and insist on trying to find the perl executable's path so they can avoid using the shell by invoking perl directly.

    The problem -- if it is the same one -- is that they insist on looking for a perl executable called 'perl' when it will be called 'perl.exe' on Windows.

    The only 'fix' (that I found) was to hack your way through the Byzantine maze of pseud--OO configuration scripts to locate the string constant and modify it. The problem is that (IIRC) the bit you need is included from a partial script with a .in extension.

    Sorry I cannot be more specific. Nor more sure that this is actually the solution.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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.
      Nor more sure that this is actually the solution

      Turns out to be the same type of thing - thanks for the pointer.

      Once I searched the Module::Build source for the string "Can't locate the perl binary", it all fell into place fairly quickly.
      In Module/Build/Base.pm there's some checking goes on - looks like they're trying to verify that the perl being used is the first perl to be found in the path. (I don't know why that needs to be done ... I doubt that it does ... but maybe they're trying to check something else altogether...)

      Everything's fine until Base.pm's _quoted_args() sub puts single quotes around C:\MinGW\perl510\bin\perl.exe so that, instead of executing:
      C:\MinGW\perl510\bin\perl.exe -MConfig=myconfig -e print -e myconfig
      this gets executed:
      'C:\MinGW\perl510\bin\perl.exe' -MConfig=myconfig -e print -e myconfig
      which produces the The filename,... error.

      A simple $cmd =~ s/'//g; just prior to the execution of $cmd fixes the problem.
      It's interesting that the same version of Module::Build (ie 0.38) on perls 5.8.0, 5.8.9, 5.12.0 and 5.14.0 does not throw up this problem. I guess there's something specific to 5.10.0 that triggers the error.

      Cheers,
      Rob

      Update: Originally copy'n'pasted the wrong string in a couple of places ... now fixed.
        looks like they're trying to verify that the perl being used is the first perl to be found in the path.

        Still don't get why they don't just let the shell do that job.

        Better still as far as I'm concerned would be to use $^X. That way, if I want to install to a perl other than my default version, I could just invoke it with the full path name from wherever it lives and not have to faff around modifying my path to get it to install in the right place.

        Doesn't $^X work on other platforms?


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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.
Re: [Win32] Math::GSL on perl 5.10.0
by Anonymous Monk on Nov 04, 2011 at 22:52 UTC