in reply to Perl 5.10.1 RC1 released for testing

Look ma, no tarballs :)

Earlier I did

$ git clone git://perl5.git.perl.org/perl.git
Now to try out perl-5.10.1-RC1
$ git checkout perl-5.10.1-RC1 HEAD is now at d792035... today's merging activity
To see what changed from 5.10.0, perl-5.10.1-RC1/Changes says
git log --name-status perl-5.10.0^..perl-5.10.1 ^f7c6915850
But that doesn't quite work yet since there is no perl-5.10.1 tag yet, but these do
git log --name-status perl-5.10.0^..^f7c6915850 git log --name-status perl-5.10.0^..^perl-5.10.1-RC1 git log --name-status perl-5.10.0^..^d792035

Replies are listed 'Best First'.
Re^2: Perl 5.10.1 RC1 released for testing
by Anonymous Monk on Aug 08, 2009 at 12:23 UTC
    Trying to build perl-5.10.1-RC1 with ActivePerl/MinGW-5.1.4.1.ppd supplied gcc version 3.4.5 (mingw-vista special r3), aborts the build with a segfault for generate_uudmap.exe. I've built bleadperl with the same setup; generate_uudmap also segfaulted, but that didn't stop the build from completing successfully. There is no problem building perl-5.10.1-RC1 with strawberry perl supplied gcc version 3.4.5 (mingw special).

    There are very few test failures, nothing serious

    op/readline.t .................................................... 7/1 +8 # Failed at op/readline.t line 92 # got 'main=ARRAY(0xa09644)es # ' # expected /(?-xism:main=ARRAY.*world)/ # Failed at op/readline.t line 101 # got 'A: world # ' # expected 'A: One # ' # Failed at op/readline.t line 102 # got 'B: One # ' # expected 'B: Two # ' op/readline.t .................................................... Fai +led 3/18 subtests
    The same test fails in bleadperl :)

    Some tests are skipped because they use shell redirection without escaping

    My firewall complains that these tests want to listen on 0.0.0.0

    ../ext/IO/t/io_multihomed.t ../ext/IO/t/io_sock.t
    Many others tests listen on 127.0.0.1 without problems :)
      Trying to build perl-5.10.1-RC1 with ActivePerl/MinGW-5.1.4.1.ppd supplied gcc version 3.4.5 (mingw-vista special r3), aborts the build with a segfault for generate_uudmap.exe.

      This problem seems to arise for some builds of MinGW but not others - the version of the mingw-runtime being used seems to be the most likely culprit. In the win32/makefile.mk you'll find the line:
      LIBC = -lmsvcrt
      Does it help if you comment out that line ? (Comment out with a '#' same as for perl.)
      There's a recent thread on p5p where that fix did work - but I'm not sure it's exactly the same problem.

      Cheers,
      Rob
        Yes, that helps building under ActivePerl/MinGW-5.1.4.1.ppd.
      'C:\Program' is not recognized as an internal or external command, operable program or batch file.

      I expect that the problem here is that you've stuck gzip.exe in a path that contains a space (namely, the space between "Program" and "Files"). Efforts are often made to cater for that type of OS/user bug .... buggered if I know why :-)
      For mine, the correct thing to do is to simply not put *anything* in a location that contains white space.

      Cheers,
      Rob
        Cleaning up path isn't a bad idea
        use Env '@PATH'; my @short = map {Win32::GetShortPathName($_) } @PATH; print 'set path=', pop @short, "\n"; print "$_\n" for map { "set path=$_;%path%" } reverse @short; __END__ ... set path=C:\PROGRA~1\GNU\GnuPG;%path% set path=C:\PROGRA~1\gnuwin32\bin;%path% ...