Strawberry website unreachable
Hi, Website will be back soon ? Cheers, Rob
Re: Strawberry Perl 5.24.2.1 released
-Original Message- From: kmx Sent: Friday, July 21, 2017 10:51 PM To: sisyph...@optusnet.com.au ; win32-vanilla@perl.org Subject: Re: Strawberry Perl 5.24.2.1 released On 21.07.2017 14:11, sisyph...@optusnet.com.au wrote: 1) What version of gcc was used to build the 64-bit perl ? (I'm assuming it would be 7.1.0, but maybe that's not the policy.) It is gcc 4.9.2 as it is 5.24.x series, gcc 7.1.0 is used in 5.26.x series. Aaah ... wasn't sure of the "rules". 2) Was perl.h patched in accordance with the patch provided to https://rt.cpan.org/Ticket/Display.html?id=121683 ? No, IMO it does not affect gcc 4.9.2. I know about this patch but I am waiting for 5.26.1. It doesn't seem to affect 5.3.0 or 5.4.0 either but it does affect 6.3.0 and later - so I'm guessing that it affects version 6 onwards. BTW, I have filed a perlbug report about this - https://rt.perl.org/Public/Bug/Display.html?id=131726 If there is no 5.26.1 till the end of August I'll release Strawberry Perl 5.26.0.2 at the beginning of September with the patch in question. Steve Hay posted today (to p5p) that "5.26.1 is slated for sometime in August". I've requested that the patch to perl.h be backported to any future releases (as well as being applied to blead) ... but who knows what will eventuate ... Cheers, Rob
Re: Strawberry Perl 5.24.2.1 released
-Original Message- From: kmx Sent: Friday, July 21, 2017 8:00 AM To: win32-vanilla@perl.org Subject: Strawberry Perl 5.24.2.1 released Strawberry Perl 5.24.2.1 is available at http://strawberryperl.com I'm curious (in a fairly idle sort of way ;-) to know 2 things: 1) What version of gcc was used to build the 64-bit perl ? (I'm assuming it would be 7.1.0, but maybe that's not the policy.) 2) Was perl.h patched in accordance with the patch provided to https://rt.cpan.org/Ticket/Display.html?id=121683 ? I know I can get the answers by downloading the perl in question, or by directly asking ... but is there some other way I can find out ? Cheers, Rob
Re: powershell compatible SPP
-Original Message- From: Chris Marshall Sent: Monday, July 03, 2017 9:24 PM To: sisyph...@optusnet.com.au ; win32-vanilla@perl.org Subject: Re: powershell compatible SPP The idea is an SPP that uses PowerShell to function and can operate on a system without cmd.exe, command.com, or batch files. Aaah ... sorry, I failed to grasp that. I don't have much interest in such a thing, after all ;-) Good luck with it, though. Cheers, Rob
Re: powershell compatible SPP
-Original Message- From: sisyph...@optusnet.com.au Sent: Monday, July 03, 2017 2:36 PM To: win32-vanilla@perl.org ; Chris Marshall Subject: Re: powershell compatible SPP When I switched to using pdl2, the history keys then became functional. Duh not correct. But if, in the powershell, I do: $env:term="" then history keys work as expected in both perldl and pdl2 shells. Cheers, Rob
Re: powershell compatible SPP
-Original Message- From: Chris Marshall Sent: Sunday, July 02, 2017 1:32 AM To: sisyph...@optusnet.com.au ; win32-vanilla@perl.org Subject: Re: powershell compatible SPP But does that provide the functionality that's required ? ... or are there some issues regarding the functionality thus obtained ? The main one is without command.com, all the .bat files for running perl scripts as programs (think pdl2 or perldl) won't run. They run ok for me in the powershell - in so far as they start up fine and I can run simple scripts on them. (Or do people want to be able to run cmdlets in the pdl2 shell ?) One thing I did notice is that the history (up/down arrow) keys don't work in the perldl shell that's run in powershell, though those keys work when the perldl shell is run in the cmd.exe shell. When I switched to using pdl2, the history keys then became functional. Anyway I think your main aim at this point was to gauge the level of interest in your proposed project, and although I'm not prepared to commit to the project, I do find it a bit interesting and would like to stay up to date with developments. Are there more detailed reports (that I can access) of the actual problems being experienced ? Cheers, Rob
Re: powershell compatible SPP
-Original Message- From: Chris Marshall Sent: Saturday, July 01, 2017 5:16 AM To: win32-vanilla@perl.org Subject: powershell compatible SPP Hi Chris, Following a conversation with Chas Owens at YAPC::NA 2017 in Alexandria, we're working on an implemention of SPP using Windows PowerShell rather than command.com and .bat files. On a Windows 10 laptop, I opened a powershell (for the first time in my life) and added the location of SPP's gcc and perl bin folders to the path: PS C:\p> $Env:Path="$Env:Path;C:\_64\strawberry5.24.0-ld\c\bin;C:\_64\strawberry5.24.0-ld\perl\bin" (I'm not proposing that as the solution - I would think you'd want to provide an alternative to portableshell.bat that does that for the user.) But does that provide the functionality that's required ? ... or are there some issues regarding the functionality thus obtained ? It seemed fine to me - whereas running SPP's portableshell.bat from inside an already existing powershell seemed to bugger up the shell's behavioural characteristics. Cheers, Rob
Fw: Strawberry Perl 5.26.0 release candidates
Hi, Sorry for the noise - re-forwarding with a more appropriate subject line. Cheers, Rob -Original Message- From: kmx Sent: Saturday, May 20, 2017 4:39 AM To: sisyph...@optusnet.com.au Cc: Alexandr Ciornii Subject: Re: Call for opinion (which gcc?) Rob, here are ZIPs for testing: http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-32bit-PDL.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-32bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-32bit.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-64bit-PDL.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-64bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-64bit.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-ld-5.26.0.1RC1-64bit-PDL.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-ld-5.26.0.1RC1-64bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-ld-5.26.0.1RC1-64bit.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-no64-5.26.0.1RC1-32bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-no64-5.26.0.1RC1-32bit.zip Feel free to post them to win32-vanilla@perl.org (unfortunately for some reason my emails to the list are being block somewhere probably by an anti filter) CCing chorny as he might be interested as well -- kmx
Fw: Call for opinion (which gcc?)
Hi, Forwarding as suggested by kmx below. Cheers, Rob -Original Message- From: kmx Sent: Saturday, May 20, 2017 4:39 AM To: sisyph...@optusnet.com.au Cc: Alexandr Ciornii Subject: Re: Call for opinion (which gcc?) Rob, here are ZIPs for testing: http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-32bit-PDL.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-32bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-32bit.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-64bit-PDL.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-64bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-5.26.0.1RC1-64bit.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-ld-5.26.0.1RC1-64bit-PDL.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-ld-5.26.0.1RC1-64bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-ld-5.26.0.1RC1-64bit.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-no64-5.26.0.1RC1-32bit-portable.zip http://strawberryperl.com/download/5.26.0.1/strawberry-perl-no64-5.26.0.1RC1-32bit.zip Feel free to post them to win32-vanilla@perl.org (unfortunately for some reason my emails to the list are being block somewhere probably by an anti filter) CCing chorny as he might be interested as well -- kmx
Re: Wrong SHA1 is calculated
Le 15/05/2017 à 16:30, sisyph...@optusnet.com.au a écrit : Unfortunately, I don't know how to get that binmode() into the one-liner's angle brackets :-( $ PERLIO=unix perl -MDigest::SHA1=sha1_hex -le "print sha1_hex <>" secure.txt 19576d392b021ac25efdca6f1886b5ce5b1090c4 Yes, I think that should give the OP the result he was seeking. Heh ... I didn't realize (until after I had posted) that this was a bash shell solution. In the cmd shell, of course, the same command simply outputs: 'PERLIO' is not recognized as an internal or external command, operable program or batch file. Best approximation I could come up with in the cmd shell was: set PERLIO=unix && perl -MDigest::SHA1=sha1_hex -le "print sha1_hex <>" secure.txt && set PERLIO= 19576d392b021ac25efdca6f1886b5ce5b1090c4 which is not quite so nice as in bash ;-) Can my cmd shell implementation be improved upon ? Cheers, Rob
Re: Wrong SHA1 is calculated
-Original Message- From: Christian Millour Sent: Tuesday, May 16, 2017 9:14 AM To: win32-vanilla@perl.org Subject: Re: Wrong SHA1 is calculated Le 15/05/2017 à 16:30, sisyph...@optusnet.com.au a écrit : Unfortunately, I don't know how to get that binmode() into the one-liner's angle brackets :-( $ PERLIO=unix perl -MDigest::SHA1=sha1_hex -le "print sha1_hex <>" secure.txt 19576d392b021ac25efdca6f1886b5ce5b1090c4 $ Yes, I think that should give the OP the result he was seeking. Nice. Cheers, Rob
Re: Wrong SHA1 is calculated
From: Martin Puppe
Sent: Monday, May 15, 2017 8:39 PM
To: win32-vanilla@perl.org
Subject: Wrong SHA1 is calculated
Hello,
I am debugging a problem with SHA1 checksums. I have found the following
handy one-liner on Stack Overflow [^1], which serves well as a minimal
example:
perl -MDigest::SHA1=sha1_hex -le "print sha1_hex <>" secure.txt
The problem is, that the result is simply not correct.Martin Puppe
The same web page presents a program which should provide the same "not
correct" result.
I've inserted "binmode $fh;" into it - which then allows it to return the
"correct" value:
#
use warnings;
use strict;
use Digest::SHA1;
die "Usage: $0 file ..\n" unless @ARGV;
foreach my $file (@ARGV) {
my $fh;
unless (open $fh, $file) {
warn "$0: open $file: $!";
next;
}
binmode $fh; # inserted by sisyphus
my $sha1 = Digest::SHA1->new;
$sha1->addfile($fh);
print $sha1->hexdigest, " $file\n";
close $fh;
}
###
If 'secure.txt' is a plain text file with Unix line endings, then that
binmode() should not be necessary - but if the text file has Windows line
endings then binmode() will prevent their translation to Unix endings (and
the program will return the result that you expect).
Unfortunately, I don't know how to get that binmode() into the one-liner's
angle brackets :-(
Maybe someone else here can chime in.
Cheers,
Rob
Re: help with 64-bit dlls for libcairo
Hi, I've just had reason to re-visit building of glib stuff with my own builds of perl. Having done that, I switched attention to x64 Strawberry 5.24.1 portable: C:\>perl -V:archname archname='MSWin32-x64-multi-thread'; C:\>perl -le "print $^X; print $];" C:\_64\strawberry5.24.1\perl\bin\perl.exe 5.024001 I'm building (in cmd.exe shell) against msys2 provided x64 gtk3 binaries. Import libs and headers are in C:\_64\msys64\mingw64\lib and C:\_64\msys64\mingw64\include. DLLs are in C:\_64\msys64\mingw64\bin. I wanted to ensure that perl and gcc came before C:\_64\msys64\mingw64\bin in the PATH so I ran: set Path=C:\_64\strawberry5.24.1\perl\bin;C:\_64\strawberry5.24.1\c\bin;C:\_64\msys64\mingw64\bin;%PATH% And I set the PKG_CONFIG_PATH env var appropriately with: set PKG_CONFIG_PATH=C:\_64\msys64\mingw64\lib\pkgconfig Then I tried building Glib-1.324. First thing I discovered was that Strawberry's pkg-config.bat was not up to the job, so I removed it. This then meant that C:\_64\msys64\mingw64\bin\pkg-config.exe would be used. Then I discover that I need to hide the msys2 ".a" static libs from the build - otherwise an attempt to link to them is made (rather than linking to the ".dll.a" import libs.) So I hide the static libs by renaming them to ".a_static". This allows 'make' to succeed, but then 'make test' throws up "The procedure entry point pthread_setname_np could not be located in the dynamic link library libwinpthread-1.dll". This happens because the Glib.dll uses the "libwinpthread-1.dll" that perl itself loaded at start up - rather than the gtk3 libwinpthread-1.dll that it needs to use. Under such a condition I know of no way of coercing Glib.dll into using the libwinpthread-1.dll that it needs to use. I can fix this, however, by removing the libwinpthread-1.dlls that are in C:\_64\strawberry5.24.1\perl\bin and C:\_64\strawberry5.24.1\c\bin. Now there's only one libwinpthread-1.dll available and 'make test' succeeds (except for the one test that usually fails for me). Install Glib-1.324 and move on to Cairo-1.106. I strike the same problem with some other static libs that need to be hidden. With those static libs hidden, we then get to 'make test', where I get: The procedure entry point __gxx_personality_seh0 could not be located in the dynamic link library libstdc++-6.dll. Different dll, same problem as with Glib - so I try removing the 2 instances of Strawberry's libstdc++-6.dll. But this time it doesn't work - all we get is a slightly different error message: The procedure entry point __gxx_personality_sj0 could not be located in the dynamic link library libstdc++-6.dll. So ... perl needs one version of libstdc++-6.dll, and Cairo needs a different version - and there is no way that I know such that we can get perl and Cairo to use different versions of the file named libstdc++-6.dll. We're snookered. One solution is to build Glib, Cairo, etc. against static libraries. This something that I have *not* tried. (But it might be do-able since MSYS2 provides us with static libs.) Another solution is to use the compiler that built the msys2 binaries (gcc-5.4.0, I think) to build perl, and then build Glib, Cairo, etc. using that perl/compiler/gtk combo. Since they all have the same libstdc++-6.dll and libwinpthread-1.dll, they should all get on famously. Typically, when snookered lie this, I create a copy of C:\_64\msys64\mingw64\bin\libstdc++-6.dll (in the same directory) named (say) xxxstdc++-6.dll. Then I edit Cairo.dll (and any other dll that needs to use C:\_64\msys64\mingw64\bin\libstdc++-6.dll) to use xxxstdc++-6.dll. It's a dreadful hack that can involve a lot of editing and renaming (through flow-on effects), but it *does* work. Anyone have any other solutions ? Cheers, Rob
Re: help with 64-bit dlls for libcairo
-Original Message- From: Dmitry Karasik Sent: Sunday, March 12, 2017 6:22 PM To: win32-vanilla@perl.org Subject: help with 64-bit dlls for libcairo libgcc_s_seh-1.dll (or is it sjlj?) It depends upon the compilers exception handling - which could dwarf2, seh or sjlj. My rule is to use a compiler that provides sjlj exception handling - and I think Strawberry does the same. (The 'gcc --version' output should mention the flavour of exception handling.) Hence, they'll have a libgcc_s_sjlj-1.dll but, if you need libgcc_s_seh-1.dll then you'll have to go to a mingw64 version of gcc that was built with seh exception handling. And I don't know what would happen if you simply stayed with your sjlj compiler and made a libgcc_s_seh-1.dll available. I would more expect that if you've got a dll that's looking for libgcc_s_seh-1.dll, then you need to switch to a gcc compiler that has that file. I believe you can statically link these particular dlls (ie libgcc_s_dw2-1.dll or libgcc_s_seh-1.dll or libgcc_s_sjlj-1.dll) into your app - thereby ensuring that they're not required at runtime. And I think this is the approach that Strawberry takes with libgcc_s_sjlj-1.dll. Maybe I'm doing it completely wrong? In any case I'd rather not build these from source, if I could avoid it. Gtk-perl is the most frustrating thing I've ever struck. It's now got to the stage that my Gtk+ installation is so out of date that I'm faced with updating it if I want to continue providing useful Glib ppm packages and that means again going through agonies that I'm not too keen on re-visiting. Cheers, Rob
Strawberry-5.24.1.1 has uusable perldoc
Hi, C:\_64\strawberry5.24.1>perldoc perldoc Invalid parameter - -R And it's the same for any other perldoc doc request (unless the requested documentation cannot be found). This problem has been discussed on perlbug ( https://rt.perl.org/Public/Bug/Display.html?id=130759 ) and raised on rt.cpan.org ( https://rt.cpan.org/Public/Bug/Display.html?id=116953 ) Just raising it here mainly as an FYI. Strawberry-5.24.1 shipped with Pod-Perldoc-3.27, though the official perl-5.24.1 release shipped with 3.25_03. I think (unchecked) that 3.25_03 does not exhibit the bug - which would make this particular issue Strawberry-specific. (I know that version 3.25_02 does not exhibit the bug.) Cheers, Rob
x64 perl-5.24.0 built using gcc-5.3.0
Hi, I generally build perl myself (using a mingw-w64 port of gcc). With these perls (both 32-bit and 64-bit) when I build a perl extension, the extension's dll that gets built has always been dependent on libgcc_s_sjlj-1.dll until 64-bit gcc-5.3.0. With the 32-bit perl-5.24.0 (built with 32-bit gcc-5.3.0) the libgcc_s_sjlj-1.dll dependency is still there, but not with 64-bit perl-5.24.0 (built with 64-bit gcc-5.3.0). For example, with the 32-bit gcc-5.3.0: C:\>objdump -x C:\MinGW\perl524_64int_ld\site\lib\auto\Math\GMPz\GMPz.dll | grep "DLL Name" DLL Name: libgcc_s_sjlj-1.dll DLL Name: msvcrt.dll DLL Name: KERNEL32.dll DLL Name: perl524.dll And with the 64-bit gcc-5.3.0: C:\>objdump -x C:\_64\perl524_530_ld\site\lib\auto\Math\GMPz\GMPz.dll | grep "DLL Name" DLL Name: msvcrt.dll DLL Name: KERNEL32.dll DLL Name: perl524.dll Does anyone know why this behaviour might be different for the 64-bit gcc-5.3.0 ? Has anyone else seen this behaviour ? Here's the gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=C:/_64/gcc-mingw-530/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-5.3.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw530/x86_64-530-posix-sjlj-rt_v4-rev0/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-sjlj-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw530/x86_64-530-posix-sjlj-rt_v4-rev0/mingw64/opt/include -I/c/mingw530/prerequisites/x86_64-zlib-static/include -I/c/mingw530/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw530/x86_64-530-posix-sjlj-rt_v4-rev0/mingw64/opt/include -I/c/mingw530/prerequisites/x86_64-zlib-static/include -I/c/mingw530/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw530/x86_64-530-posix-sjlj-rt_v4-rev0/mingw64/opt/lib -L/c/mingw530/prerequisites/x86_64-zlib-static/lib -L/c/mingw530/prerequisites/x86_64-w64-mingw32-static/lib ' Thread model: posix gcc version 5.3.0 (x86_64-posix-sjlj-rev0, Built by MinGW-W64 project) Cheers, Rob
Re: Portable zip turns out to be relocatable instead
-Original Message- From: kmx Sent: Saturday, May 14, 2016 11:36 PM To: win32-vanilla@perl.org Subject: Re: Portable zip turns out to be relocatable instead Now it should be replaced with the correct ZIP - new SHA256 checksum: 3b01ee789a6424704b31b0089c47caf67adda91860d192e4a80ed47b278f0671, new filesize: 151630709 I apologise but co-release of perls 5.22.2+5.24.0 was a bit more hectic than I would like it to be. I understand. I saw your posts to p5p about this - and I saw the apathy/antipathy of the responses (Steve Hay excepted). Cheers, Rob
Portable zip turns out to be relocatable instead
Hi, I grabbed: http://strawberryperl.com/download/5.22.2.1/strawberry-perl-ld-5.22.2.1-64bit-PDL.zip but (unless I've messed something up) I'm finding it's "relocatable", whereas I expected it to be "portable". No such problem with the 5.24.0 version. Cheers, Rob
Bug in webpage ?
Hi, As regards http://strawberryperl.com/releases.html, line 43 of the html source is: 5.24.0.1 / 32bit - href="release-notes/5.24.0.1-32bit.html">Release Notes I suspect we need to =~ s/32/64/g that line. Cheers, Rob
A portableshell.bat oddity
Hi, I was thinking of making this post a reply to Dave Benham's post "Improved portableshell.bat for Strawberry Perl". However, I'm not at all sure that the issue I've been facing is related to the issues Dave has raised. I have 8 separate installations of Strawberry Perl, each with their own portableshell.bat. A month or two back I discovered that the "up" and "down" arrow (history) keys were no longer working on these "portableshell.bat" shells. That is, I could no longer use those keys to go back and forth through the previous commands that I had run - pressing those keys did absolutely nothing. This affected only the "portableshell.bat" shells - and it affected all 8 of them. The history keys were still working fine with shells opened up by clicking on "cmd.exe". I'm quite sure that the history keys originally worked fine in the "portableshell.bat" shells, and that they became non-functioning no more than 3 months ago. Today, I opened up one of the "portableshell.bat" shells, and noticed that the following environment variables were set for portableshell, but unset for cmd: drive=C:\_32\strawberry5.22.0\ drivep=C:\_32\strawberry5.22.0 So, in the open "portableshell.bat" shell, I cleared both of those environment variables (but only for the open shell) - and the history keys immediately started working fine again. I then reset those 2 environment variables to their original values - and the history keys continued to work. I then opened each of the other 7 "portableshell.bat" shells - and the history keys immediately worked correctly for them, too. It's as though the momentary clearing of those environment variables toggled something on this (Windows 7) machine that switched the history keys back on for the Strawberry Perl shells. So, the problem has been fixed but I still don't understand it at all - nor do I know how to re-create it. Any explanations ? Oddly, the usages of '#' (discussed at http://stackoverflow.com/questions/35867036/usage-of-pound-sign-in-batch-files) that ultimately led to Dave's post to this list also involve references to "drive" and "drivep". Cheers, Rob
Re: Build perl without libgcc_s_sjlj-1 dependency
-Original Message- From: Robert Eden Sent: Friday, October 02, 2015 3:04 AM To: win32-vanilla@perl.org Subject: Re: Build perl without libgcc_s_sjlj-1 dependency I documented the procedure here: http://wiki.xmltv.org/index.php/XMLTVexeBuild Thanks Robert. It was your thread that I eventually dug up - though your wiki provides a more comprehensive presentation, of course. Does anyone have any comments on "pros and cons" of building perl with these runtime dependencies versus having them statically linked in ? Cheers, Rob
Re: Build perl without libgcc_s_sjlj-1 dependency
-Original Message-
From: sisyph...@optusnet.com.au
Sent: Thursday, October 01, 2015 2:45 PM
To: win32-vanilla@perl.org
Subject: Build perl without libgcc_s_sjlj-1 dependency
Is there someone here who can provide info/link to building perl (using
mingw port of gcc) without it being dependent on libgcc_s_sjlj-1.dll,
libstdc++-6.dll ?
No matter - I finally (re)found:
http://www.nntp.perl.org/group/perl.win32.vanilla/2014/08/msg579.html
and followed that advice to successfully build a perl-5.16.0 that had no
runtime dependency upon the 2 gcc dll files.
I then used that perl to build Math::Float128, and copied it across to
ActivePerl-5.16.0.
As I expected, it made no difference and ActivePerl is still producing:
C:\_32>perl -MMath::Float128 -le "$x=Math::Float128->new('2.3');print $x;"
1.28255230868747473742425564582366e-4937
At least I've ruled out the possibility that the runtime dependency on the 2
gcc dll's is the cause of the problem.
Must be something else.
This new mingw perl.exe has a runtime dependency on kernel32.dll, whereas
the ActivePerl one doesn't.
And the new mingw perl516.dll has a runtime dependency on ws2_32.dll,
whereas the ActivePerl one doesn't.
Other than that, runtime dependencies are identical, right down to the
actual dll's that are being loaded.
I'll probably raise this on perlmonks (where it's just as off-topic as it is
here) at some stage in the future.
Cheers,
Rob
Build perl without libgcc_s_sjlj-1 dependency
Hi,
Is there someone here who can provide info/link to building perl (using
mingw port of gcc) without it being dependent on libgcc_s_sjlj-1.dll,
libstdc++-6.dll ?
(I'm familiar enough with building perl using mingw - I'm just seeking
advice re the mechanism for removing the aforementioned dependencies.)
I provide the following by way of information. Feel free to comment on it.
Also feel free to ignore it.
My mingw-built Math::Float128 ppm package doesn't work correctly with
ActivePerl build 1600 (5.16.0).
Essentially it works fine the only problem arises when it comes to
printing out the actual value contained in the Math::Float128 object:
C:\_32>perl -MMath::Float128 -le "$x=Math::Float128->new('2.3');print $x;"
1.28255230868747473742425564582366e-4937
The expected result is:
C:\_32>perl -MMath::Float128 -le "$x=Math::Float128->new('2.3');print $x;"
2.3e+00
I'm thinking this must be some runtime issue, so I've been comparing the dll
files that my mingw-built perl-5.16.0 loads with the dll's that ActivePerl
loads.
I was thinking they must be loading different C runtimes but, alas, the
evidence is that they're loading the very same msvcrt.dll.
They also load the same system dll's.
Only difference I can find is that the mingw build's perl516.dll has
dependencies upon libgcc_s_sjlj-1.dll, libstdc++-6.dll and the system
WS2_32.dll, whereas the AS perl516.dll does not.
I don't know how to remove the WS2_32.dll dependency, but at least I can
start by building a mingw-built perl that doesn't have the dependencies on
the 2 helper dll's.
Then build Math::Float128 using that perl and see if that works any better
with ActivePerl.
Instinctively I feel that it won't make any difference, but I can't think of
anything else to try.
It's quite likely that other versions of ActivePerl (not just 5.16.0) are
affected in the same way, but this is untested.
Cheers,
Rob
Re: Mixing of forward and back slashes in paths?
-Original Message- From: L. Walsh Sent: Saturday, March 07, 2015 5:21 PM To: sisyph...@optusnet.com.au Cc: Strawberry Perl Subject: Re: Mixing of forward and back slashes in paths? And if you do: $^X = "C:\Strawberry\perl\bin\perl.exe"; I don't do it -- perl does it. Look at the listing for PERL5LIB at the bottom of the report: The setting of these things are determined by what's in the perl source distro and ought therefore be dealt with at the perl source level - so it needs to be achieved by patching the perl source (and perhaps some of the core modules). I build perl from source myself - and see the same mixture of forward and backward slashes in paths. I don't see it as being Strawberry's responsibility to deal with this (but I have no official position with the Strawberry project). On Windows 7, I strike occasions where forward slashes are unworkable and need to be replaced by backslashes - so I'd be very annoyed if perl were ever to forbid the backslash in a path (or automatically convert it to a forward slash). Here's an example of forward slashes being unworkable on my Windows 7 box. It relies on the existence of ../doc.txt. ### use warnings; use strict; my $f1 = '../doc.txt'; my $f2 = "../doc.txt"; my $f3 = '..\doc.txt'; my $f4 = "..\\doc.txt"; # will fail warn "failed to copy $f1 to dac.txt" if system 'copy', $f1, 'dac.txt'; # will fail warn "failed to copy $f2 to dec.txt" if system 'copy', $f2, 'dec.txt'; # will succeed warn "failed to copy $f3 to dic.txt" if system 'copy', $f3, 'dic.txt'; # will succeed warn "failed to copy $f4 to duc.txt" if system 'copy', $f4, 'duc.txt'; ### I don't know if the behaviour I see from this script is common. Even if perl were to convert the backslash to forward slash for display purposes only, I would be very annoyed. If I were to "say $f1;" in the above script, I would expect to see what's actually there - namely "..\doc.txt". But it's not me you need to convince about this - it's p5p or kmx (who does have an official position with the Strawberry project). I suspect it's now too late for either p5p or kmx to do anything about this for the upcoming 5.22 - maybe take it up in the next round of blead releases (5.23) ? Cheers, Rob
Re: Mixing of forward and back slashes in paths?
-Original Message- From: L. Walsh Sent: Saturday, March 07, 2015 5:00 AM To: Strawberry Perl Subject: Mixing of forward and back slashes in paths? I recently was looking into a CPAN tester report P-1.1.24: - MSWin32-x86-multi-thread-64int / 5.20.2: - FAIL http://www.cpantesters.org/cpan/report/bc273757-6c01-1014-a765-afcf632b568brt You mean: http://www.cpantesters.org/cpan/report/bc273757-6c01-1014-a765-afcf632b568b The last win32 version I'd tested with was a bit ago @ in 5.14 and it didn't have this problem. Sorry - I couldn't work out what it is that you're asking about. And I couldn't spot anything in the testers report that indicates any problem with any of the paths. Both "\" and "/" are acceptable (and essentially equivalent) where used (AFAICS). If you do: $test = "C:\this"; what do you expect to be output by: printf "%s\n", $test; And if you do: $^X = "C:\Strawberry\perl\bin\perl.exe"; what do you expect to be output by: printf "5.20 path for perl: $^X???\n"; Cheers, Rob
Re: How to hack portable Strawberry's libpth
Too easy – thanks.
Cheers,
Rob
From: kmx
Sent: Monday, February 23, 2015 4:05 AM
To: win32-vanilla@perl.org
Subject: Re: How to hack portable Strawberry's libpth
Hi Rob,
portable.perl file (in strawberry portable perl root dir) is the place where
all portable dark magic takes place.
--
kmx
On 22.2.2015 14:25, sisyph...@optusnet.com.au wrote:
Hi,
Having installed a portable build of Strawberry 5.20.0, how do I then alter
$Config{libpth} - such that the alteration to $Config{libpth} is already in
place every time I open up an instance of the strawberry shell ?
For my own Windows perls, I would do this by editing appropriately the libpth
entry in Config_heavy.pl and Config.pm, but Stawberry seems to be reading
libpth from some other source(s) as the entries in Config_heavy.pl and
Config.pm don't even match $Config{libpth}.
And changing the libpth entries in those 2 files doesn't seem to be having
any effect at all.
Cheers,
Rob
How to hack portable Strawberry's libpth
Hi,
Having installed a portable build of Strawberry 5.20.0, how do I then alter
$Config{libpth} - such that the alteration to $Config{libpth} is already in
place every time I open up an instance of the strawberry shell ?
For my own Windows perls, I would do this by editing appropriately the
libpth entry in Config_heavy.pl and Config.pm, but Stawberry seems to be
reading libpth from some other source(s) as the entries in Config_heavy.pl
and Config.pm don't even match $Config{libpth}.
And changing the libpth entries in those 2 files doesn't seem to be having
any effect at all.
Cheers,
Rob
Re: Does Strawberry Perl has the PPM GUI, too?
From: Alex Becker Sent: Thursday, September 11, 2014 6:42 AM Although it's not noted on strawberryperl.com, I found out that Strawberry Perl has / ships with PPM. But, is it the command line version or does it have this nifty nice-looking GUI, too? Just the command line version. AIUI, the more recent versions of PPM that provide the GUI are the property of ActiveState, and cannot be provided with Strawberry for legal reasons. Cheers, Rob
Re: statically linked Strawberry Perl for use with PerlApp?
-Original Message- From: kmx Try to run dmake like this: dmake "BUILDOPTEXTRA=-static-libgcc -static-libstdc++" I wonder ... is a perl built with that option binary-compatible with a perl that wasn't built with that option ? Nothing to do with this thread, but if they *are* binary-compatible, then I see here a way of creating PPM packages that don't have a dependency on those 2 dlls. No big deal, either way - just curious. And like you point out, there may be other side-effects Cheers, Rob
Re: statically linked Strawberry Perl for use with PerlApp?
-Original Message-
From: Octavian Rasnita
Sent: Tuesday, June 24, 2014 2:28 AM
Do you know if that static Perl can be used if the entire directory is
moved on another path?
Seems ok to me after I moved it:
C:\Windows\System32>perl-static -le "print $^X;print for @INC"
C:\_64\moved\static_perl520_482\bin\perl-static.exe
C:/_64/moved/static_perl520_482/site/lib
C:/_64/moved/static_perl520_482/lib
.
Is that what you meant ?
There are, of course, then a number of incorrect Config settings - eg:
C:\Windows\System32>perl-static -MConfig -le "print $Config{installbin}"
c:\_64\static_perl520_482\bin
but that's no different to any other perl that gets moved.
The static-perl.exe does have a runtime dependency upon libgcc_s_sjlj-1.dll
and libstdc++-6.dll - hence kmx's recommendation that perl be built with
"-static-libgcc -static-libstdc++" (which I haven't tried).
Cheers,
Rob
Re: statically linked Strawberry Perl for use with PerlApp?
-Original Message- From: Robert Eden That should work! I'll let the list know how it goes (and if it works with PerlApp) Yes, please do - that would be interesting. Cheers, Rob
Re: statically linked Strawberry Perl for use with PerlApp?
-Original Message- From: Robert Eden Is there any documentation on compiling my own version of Strawberry? I don't see any source code mentioned on the web page. Well - you could just build your own perl from source using (say) the compiler and dmake that shipped with Strawberry. You just grab the official perl 5.20.0 source, put your strawberry/c/bin folder at the beginning of the PATH, edit the (largely self-documenting) win32/makefile.mk appropriately, then cd to that win32 folder and run: dmake dmake test dmake install Attached is the win32/makefile.mk I've just used to build a 64-bit static perl-5.20.0 using Strawberry Perl-5.20.0 compiler (64-bit gcc-4.8.2). It installs perl into C:\_64\static_perl520_482. (Amend it if you want to install perl elsewhere.) It specifies that the compiler is in C:\_64\strawberry5.20.0\c (Amend that if it's not correct.) And it specifies an EXTRALIBDIRS setting that's incorrect for you. You'll want to set it to something like: EXTRALIBDIRS*= C:\_64\strawberry5.20.0\c\x86_64-w64-mingw32\lib C:\_64\strawberry5.20.0\c\lib\gcc\x86_64-w64-mingw32\4.8.2 (depending upon where those folders actually are on your machine). Apart from that, it should be right to go for you. There were a few (three, I think) test script failures during 'dmake test' nothing to worry about. It seems to install dynamic perl.exe, perl5.20.0.exe and wperl.exe (and perl520.dll) along with a (large) static perl executable called perl-static.exe. So it's the perl-static.exe you'll want to be using. I've no idea what sort of mileage you'll get out of that ;-) And, of course, FAIK, there could already be a static Strawberry perl available somewhere (or kmx might even be busy building one for you right now.) Cheers, Rob makefile.mk Description: Binary data
Re: statically linked Strawberry Perl for use with PerlApp?
From: Robert Eden Sent: Monday, June 23, 2014 4:20 AM Hi Robert, I've looked through the list archives and google searches, but don't see any Strawberry+PerlApp success stories. An alternative would be to install Par::Packer and use its pp utility to create the exe. I believe that 'pp' provides, among other things, an option that enables you to pack in any modules/dlls that don't get picked up automatically. Cheers, Rob
Re: Run an external program and capture its output
-Original Message- From: sisyph...@optusnet.com.au This is one that comes up from time to time - it's not specific to Strawberry Perl, and has to do with file associations and something else a registry setting ? ... I can never remember the details, nor of how to search for it. Aaah ... here's the solution I was thinking of: http://www.perlmonks.org/?node_id=1024609 Cheers, Rob
Re: Run an external program and capture its output
From: John Emmas Sent: Thursday, April 17, 2014 4:47 PM my_perl_script.pl > output.txt This is one that comes up from time to time - it's not specific to Strawberry Perl, and has to do with file associations and something else a registry setting ? ... I can never remember the details, nor of how to search for it. If it's the one I'm thinking of then this works: perl my_script.pl > output.txt It's just when you make use of file associations to run a script that you lose the redirection - and it's a simple fix once you find out what it is. Surely someone here knows what I'm alluding to ... and how to remedy it ? Cheers, Rob
Re: 'INC' paths for Perl
-Original Message- From: John Emmas So my best guess is that this is some kind of Perl configuration error. When I installed Strawberry Perl on my new Windows 8 box, should I have run some kind of config utility so that it would learn the relevant paths for my new machine? Seems you're building this "glibmm" library in the msys shell and you want Strawberry Perl to be found. However, msys's own perl is being found first - and is therefore being used instead of Strawberry Perl. If you re-arrange your path so that StrawberryPerl is at the very beginning, then I think your problem will vanish. export PATH=/c/strawberry/perl/bin:$PATH Cheers, Rob
Re: 'INC' paths for Perl
-Original Message- From: John Emmas So my best guess is that this is some kind of Perl configuration error. When I installed Strawberry Perl on my new Windows 8 box, should I have run some kind of config utility so that it would learn the relevant paths for my new machine? Seems you're building this "glibmm" library in the msys shell and you want Strawberry Perl to be found. However, msys's own perl is being found first - and is therefore being used instead of Strawberry Perl. If you re-arrange your path so that StrawberryPerl is at the very beginning, then I think your problem will vanish. export PATH=/c/strawberry/perl/bin:$PATH Cheers, Rob
Re: quadmath.h's expq() crashes at runtime
-Original Message-
From: kmx Sent: Monday, November 25, 2013 8:41 AM To:
win32-vanilla@perl.org Subject: Re: FYI: quadmath.h's expq() crashes at
runtime
Hi Rob,
On 5.10.2013 17:06, sisyph...@optusnet.com.au wrote:
> Hi,
>
> It's no big deal, but current Strawberry Perl 32-bit and 64-bit
> compilers create executables that crash when expq() is called.
>
> Here's the minimalistic demo script:
>
>
> #include
>
> int main (void) {
> __float128 r;
>
> r = expq(2.0Q);
> r = sqrtq(2.0Q);
> r = fabsq(2.0Q);
> r = sinq(2.0Q);
> r = logq(2.0Q);
> r = cosq(2.0Q);
>
> return 0;
> }
>
>
>
> The resultant executable crashes when run, but remove the expq() call
> and there's no problem. (Link to -lquadmath when building the above
> program.)
>
> It's not just MinGW64's gcc-4.6.3 compilers that are affected. I find
> the same with their 64-bit gcc-4.7.0, and 4.8.1 compilers. (I haven't
> tested any other MinGW64 compilers.)
>
> I've also found that mingw.org's gcc-4.7.0 does *not* suffer this
> problem; nor does Ubuntu's gcc-4.6.3 ... so I guess I probably should
> report this to the mingw64 project.
>
> BTW, the perl relevance here is that, because of this bug,
> Math::Float128 crashes its test suite when expq() gets called. But I
> don't think that there's a high demand for this module, so I wouldn't be
> too concerned about that aspect.
I am afraid I cannot do much about expq crash unless there is newer
version of gcc and/or mingw-w64 runtime which does not suffer from this.
Yes - I subsequently reported the problem to the mingw64 mailing list, where
it was confirmed as a bug in their compilers.
I don't know when/if it will be fixed. I didn't actually file a bug report
anywhere - mainly because I don't know offhand where to file such a report,
and no-one replied when I asked about that on the mailing list.
In the meantime, I've changed the relevant XS code so that if
__MINGW64_VERSION_MAJOR is defined, instead of doing expq(p), it does
powq(e,p) - and that works fine.
>
> Also of slight relevance to Strawberry Perl is the fact that
> c/lib/gcc/[whatever]-w64-mingw32/4.6.3 is not in $Config{libpth}.
> As a consequence perl does not automatically find -lquadmath when the
> Math::Float128 Makefile.PL is run, and perl therefore removes the link.
> (The gcc linker can find -lquadmath without any help at all ... but it
> won't look for that library if perl has removed the link.)
As for this part you mean using something like this:
libpth='C:\strawberry\c\lib C:\strawberry\c\x86_64-w64-mingw32\lib
C:\strawberry\c\lib\gcc\x86_64-w64-mingw32\4.7.3'
right?
Yes - and similarly, for the 32-bit compiler, we want
C:\strawberry\c\lib\gcc\i686-w64-mingw32\4.7.3 added to libpth. (Not sure if
you're upgrading the compiler to "4.7.3" or whether you meant "4.6.3" ...
I'll find out soon enough ;-)
Cheers,
Rob
FYI: quadmath.h's expq() crashes at runtime
Hi,
It's no big deal, but current Strawberry Perl 32-bit and 64-bit compilers
create executables that crash when expq() is called.
Here's the minimalistic demo script:
#include
int main (void) {
__float128 r;
r = expq(2.0Q);
r = sqrtq(2.0Q);
r = fabsq(2.0Q);
r = sinq(2.0Q);
r = logq(2.0Q);
r = cosq(2.0Q);
return 0;
}
The resultant executable crashes when run, but remove the expq() call and
there's no problem. (Link to -lquadmath when building the above program.)
It's not just MinGW64's gcc-4.6.3 compilers that are affected. I find the
same with their 64-bit gcc-4.7.0, and 4.8.1 compilers. (I haven't tested any
other MinGW64 compilers.)
I've also found that mingw.org's gcc-4.7.0 does *not* suffer this problem;
nor does Ubuntu's gcc-4.6.3 ... so I guess I probably should report this to
the mingw64 project.
BTW, the perl relevance here is that, because of this bug, Math::Float128
crashes its test suite when expq() gets called. But I don't think that
there's a high demand for this module, so I wouldn't be too concerned about
that aspect.
Also of slight relevance to Strawberry Perl is the fact that
c/lib/gcc/[whatever]-w64-mingw32/4.6.3 is not in $Config{libpth}.
As a consequence perl does not automatically find -lquadmath when the
Math::Float128 Makefile.PL is run, and perl therefore removes the link. (The
gcc linker can find -lquadmath without any help at all ... but it won't look
for that library if perl has removed the link.)
Cheers,
Rob
Re: msys for SP
-Original Message- From: kmx Is there a Strawberry distro for download that includes the msys shell ? The easiest way is to get Mark Dootson's all-in-one pack from http://sourceforge.net/projects/perlmingw/files/MSYS%20Environment%20for%20End%20Users/ Ok - thanks for the link. Cheers, Rob
msys for SP
Hi, Is there a Strawberry distro for download that includes the msys shell ? Presumably, msys is readily available as a separate download, so I guess it's no big deal if there isn't ... just wondering. Cheers, Rob
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
-Original Message- From: kmx > ActivePerl binaries (ppm packages) will not be usable on the 64int > architecture Strawberry Perl - unless, of course, ActiveState also start > providing packages for the 64int architecture. (I've no idea what > ActiveState are planning to do in this regard.) > I doubt that many Strawberry users (if any) would be affected by this, > and I don't regard it as a stopper. On the other hand ActiveState ppm repositories use newer ppm format than ppm utility included in strawberry perl is able to handle. So it is not even today easily possible to install ppm from ActiveState repo into Oh yes ... I think I recently discovered that there's quite a few hoops to jump through if you want to 'ppm install' from AS repo to Strawberry Perl. (Although I build a few ppm packages, I rarely actually use ppm - and I keep losing track of the capabilities of this utility.) > (Will 32int Strawberry builds still be available for anyone who wants > one ?) No, my idea is just one and only one 32bit strawberry perl 5.18.x with 64int. Good - that keeps it nice and simple. > One other thing to consider with 5.18 Strawberry is whether it should be > COW-enabled or not. > Until recently, the p5p plan was to make 5.18 COW-enabled, but that has > now been postponed to 5.20 (which will definitely be COW-enabled). > As the plan currently stands, 5.18 will build as COW-disabled by > default - but there's an option to build it COW-enabled (which p5p are > encouraging module authors to use - mainly to have them avoid rude > shocks when 5.20 does come along). As for COW I am gonna follow perl core default behaviour. I've no problems with that. I intend to have both COW-enabled and COW-disabled builds of 5.18.0, but I'm aiming to build ppm packages for COW-disabled only. Cheers, Rob
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
-Original Message- From: kmx Hi, is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry Perl 5.18.x series ? I have done some testing with PDL guys approx a year ago on 5.16.0 (I guess Rob is also subscribed to this list) and AFAIK it works. I've been testing it continually over the last year or so. Every module I build (not just PDL), I've been building on USE_64_BIT_INT - for both 5.16.0 and current blead (5.17.x). I haven't struck any problems at any time that were related to the 64int architecture. I can think of only one con: ActivePerl binaries (ppm packages) will not be usable on the 64int architecture Strawberry Perl - unless, of course, ActiveState also start providing packages for the 64int architecture. (I've no idea what ActiveState are planning to do in this regard.) I doubt that many Strawberry users (if any) would be affected by this, and I don't regard it as a stopper. (Will 32int Strawberry builds still be available for anyone who wants one ?) As regards the ppm packages that I provide, they'll be available for both the 64int and 32int architectures. Pros: 1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin without any special hacking that was needed for 5.16.0 2/ PDL users are gonna like it 3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit strawberry perl 4/ Couple of others asking me privately will appreciate it (they ask: why 32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?) One other thing to consider with 5.18 Strawberry is whether it should be COW-enabled or not. Until recently, the p5p plan was to make 5.18 COW-enabled, but that has now been postponed to 5.20 (which will definitely be COW-enabled). As the plan currently stands, 5.18 will build as COW-disabled by default - but there's an option to build it COW-enabled (which p5p are encouraging module authors to use - mainly to have them avoid rude shocks when 5.20 does come along). I guess Strawberry Perl would just go with the default option - though I don't have any personal preference in either direction. Cheers, Rob
Problem with Math-Int128-0.07 on x64 Strawberry Perl
Hi, I'm not personally asking for any help with this, but if anyone here is interested in solving the problem, I'm sure the Math::Int128 author would appreciate the assistance. I did file a bug report about it ( https://rt.cpan.org/Ticket/Display.html?id=82369 ) but then found that, having made (what I hope is) some headway, I'm not really smart enough to be of great assistance. In a nutshell, if I "#include " in Int128.xs, then Math-Int128-0.07 compiles fine (and without any compiler warnings) on my x64 strawberry-perl 5.16.0.1. But 'dmake test' presents a pop-up, very early on, complaining that "perl.exe has stopped working" when the first test script gets to the line: my $k = (int128(1) << 60) + 255; Anyway ... if someone here is interested in solving this, then please feel free to view the bug report ... and *do* chime in if you're able to help. Note that although the bug report's subject specifies the x64 gcc-4.7.0 compiler, the same *does* apply to x64 strawberry-perl 5.16.0.1 and Strawberry's x64 gcc-4.6.3 compiler. Cheers, Rob
