Strawberry Perl 5.24.2.1 released
Strawberry Perl 5.24.2.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.24.2.1-64bit.html http://strawberryperl.com/release-notes/5.24.2.1-32bit.html I would like to thank our sponsor Enlightened Perl Organisation [http://www.enlightenedperl.org] for resources provided to our project. -- kmx
Re: Strawberry-5.24.1.1 has uusable perldoc
Quick fix: cpanm http://strawberryperl.com/package/kmx/perl-modules-patched/Pod-Perldoc-3.27_patched.tar.gz On 14.02.2017 1:25, sisyph...@optusnet.com.au wrote: 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
Re: Improved portableshell.bat for Strawberry Perl
Those of you interested in portableshell.bat might be interested in the latest changes available at: https://github.com/StrawberryPerl/Perl-Dist-Strawberry/blob/master/share/portable/portableshell.bat -- kmx On 15.03.2016 11:40, kmx wrote: Hello Dave, The script in question is here https://github.com/StrawberryPerl/Perl-Dist-Strawberry/blob/master/share/portable/portableshell.bat So the easiest way is to fork https://github.com/StrawberryPerl/Perl-Dist-Strawberry and send a pull request -- kmx On 13.3.2016 15:58, Dave Benham wrote: I am not a regular Perl user, but I am a Windows batch file enthusiast: top All-Time batch-file contributer at StackOverflow <http://stackoverflow.com/tags/batch-file/topusers>, ID=dbenham I ran across the portableshell.bat file used by Portable Strawberry Perl in the following StackOverflow question: http://stackoverflow.com/q/35867036/1012053 There are a number of problems with that script that lead to unnecessary limitations: * The root path of Portable Strawberry Perl cannot contain space, equal (=), semicolon (;), ampersand (&), or caret (^) * The script will fail if the existing PATH contains an unquoted ampersand or caret Plus there are other esoteric issues that could use improvement. I've developed (and tested) a significantly improved portableshell.bat script that I would like to contribute. I joined GitHub, but have no idea how to proceed any further. Dave Benham
Re: Portable zip turns out to be relocatable instead
On 14.5.2016 1:58, sisyph...@optusnet.com.au wrote: 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. Good catch. 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. -- kmx
Re: Bug in webpage ?
Fixed, thanks for reporting this typo. -- kmx On 13.5.2016 14:13, sisyph...@optusnet.com.au wrote: 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
Strawberry Perl 5.24.0.1 released
Strawberry Perl 5.24.0.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.24.0.1-64bit.html http://strawberryperl.com/release-notes/5.24.0.1-32bit.html I would like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Strawberry Perl 5.22.2.1 released
Strawberry Perl 5.22.2.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.22.2.1-32bit.html http://strawberryperl.com/release-notes/5.22.2.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: Improved portableshell.bat for Strawberry Perl
Hello Dave, The script in question is here https://github.com/StrawberryPerl/Perl-Dist-Strawberry/blob/master/share/portable/portableshell.bat So the easiest way is to fork https://github.com/StrawberryPerl/Perl-Dist-Strawberry and send a pull request -- kmx On 13.3.2016 15:58, Dave Benham wrote: I am not a regular Perl user, but I am a Windows batch file enthusiast: top All-Time batch-file contributer at StackOverflow <http://stackoverflow.com/tags/batch-file/topusers>, ID=dbenham I ran across the portableshell.bat file used by Portable Strawberry Perl in the following StackOverflow question: http://stackoverflow.com/q/35867036/1012053 There are a number of problems with that script that lead to unnecessary limitations: * The root path of Portable Strawberry Perl cannot contain space, equal (=), semicolon (;), ampersand (&), or caret (^) * The script will fail if the existing PATH contains an unquoted ampersand or caret Plus there are other esoteric issues that could use improvement. I've developed (and tested) a significantly improved portableshell.bat script that I would like to contribute. I joined GitHub, but have no idea how to proceed any further. Dave Benham
Strawberry Perl 5.22.1.3 + 5.20.3.3 released
Strawberry Perl 5.22.1.3 and 5.20.3.3 are available at http://strawberryperl.com Both contain security fixes for CVE-2015-8607 + CVE-2015-8608 + CVE-2016-2381 + the latest openssl. More details in Release Notes: http://strawberryperl.com/release-notes/5.22.1.3-64bit.html http://strawberryperl.com/release-notes/5.22.1.3-32bit.html http://strawberryperl.com/release-notes/5.20.3.3-64bit.html http://strawberryperl.com/release-notes/5.20.3.3-32bit.html A note for PDL and long-double fans: from http://strawberryperl.com/releases.html you can download experimental strawberry-perl-ld-5.22.1.3-64bit-PDL.zip <http://strawberryperl.com/download/5.22.1.3/strawberry-perl-ld-5.22.1.3-64bit-PDL.zip> I would like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Strawberry Perl 5.22.1.2 + 5.20.3.2 released
Strawberry Perl 5.22.1.2 and 5.20.3.2 are available at http://strawberryperl.com Both contain security fixes for CVE-2015-8607 + CVE-2015-8608 More details in Release Notes: http://strawberryperl.com/release-notes/5.22.1.2-64bit.html http://strawberryperl.com/release-notes/5.22.1.2-32bit.html http://strawberryperl.com/release-notes/5.20.3.2-64bit.html http://strawberryperl.com/release-notes/5.20.3.2-32bit.html I would like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: Strawberry Perl 5.22.1.1 released
On 18.12.2015 18:37, John Maag via win32-vanilla wrote: How does one request a module to be added to Stawberry perl? I would like to request Filesys::DfPortable be added Simply open a "bug" via https://rt.cpan.org/Public/Dist/Display.html?Name=Perl-Dist-Strawberry -- kmx
Strawberry Perl 5.22.1.1 released
Strawberry Perl 5.22.1.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.22.1.1-32bit.html http://strawberryperl.com/release-notes/5.22.1.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: Perl Win64 DBD-Pg: how is it built?
On 21.10.2015 10:34, Bram Stappers wrote: Hello, I was wondering how Strawberry Perl compiles DBD-Pg for 64-bit Windows. In http://strawberryperl.com/release-notes/5.20.3.1-64bit.html I see that PostgreSQL driver DBD-Pg is included in Strawberry Perl 64bit. I was wondering how it is done. I did have a look at https://github.com/StrawberryPerl? in an attempt to discover if anything special was done, but was unable to find anything. In strawberry perl 5.22.0.1 there is 1/ client library postgresql-9.4.1 built with this little patch (you should find it in your c:\strawberry\licenses\postgresql\postgresql-9.4.1.diff ) diff -r -u -w --strip-trailing-cr postgresql-9.4.1.original/src/template/win32 postgresql-9.4.1/src/template/win32 --- postgresql-9.4.1.original/src/template/win322015-05-19 13:38:06.928673700 +0200 +++ postgresql-9.4.1/src/template/win322015-05-19 13:36:05.180254800 +0200 @@ -3,4 +3,4 @@ # --allow-multiple-definition is required to link pg_dump because it finds # pg_toupper() etc. in both libpq and pgport # --disable-auto-import is to ensure we get MSVC-like linking behavior -LDFLAGS="-Wl,--allow-multiple-definition -Wl,--disable-auto-import" +LDFLAGS="-Wl,--allow-multiple-definition" 2/ perl module DBD-Pg-3.5.1 installed by simply running: cpanm DBD::Pg I have experienced some troubles related to DBD::Pg + 64bit mingw-w64 when trying to build perl with extra compiler option -D__USE_MINGW_ANSI_STDIO I have not investigated why but DBD::Pg fails even to compile (no other module had a problem with __USE_MINGW_ANSI_STDIO). -- kmx
Strawberry Perl 5.20.3.1 released
Strawberry Perl 5.20.3.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.20.3.1-32bit.html http://strawberryperl.com/release-notes/5.20.3.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: source code for the 5.16.1.1 release
Yes, that's it. -- kmx On 15.8.2015 0:19, Joe Malcolm wrote: Right, but can I expect that: svn co http://svn.code.sf.net/p/mingw-w64/code/trunk@4936 Would get me the right version? Joe On Aug 14, 2015, at 15:59 , kmx mailto:k...@atlas.cz>> wrote: Hi, 4936 is SVN revision number. After mingw-w64 project had migrated to git I am not quite sure what is the corresponding git commit. -- kmx On 14.8.2015 20:01, Joe Malcolm wrote: First, thanks a lot for your work on Strawberry Perl - it’s made my life quite a bit easier. I am wondering how to find the source code for the "mingw-w64-crt” component of this release. On http://strawberryperl.com/release-notes/5.16.1.1-32bit.html it’s listed as: mingw-w64-crt_2.x_r4936 http://mingw-w64.sourceforge.net/ But r4936 does not seem to be available in the git repository. E.g.: git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 mingw-w64-mingw-w64 gives me a repo which seems to go from 4934 to 4950: commit 9ea33d20a97d5f8812233c2d6682af2461707df1 Author: Ozkan Sezer mailto:seze...@gmail.com>> Date: Tue Apr 10 08:00:51 2012 + _mingw.h (__int128, __SIZEOF_INT128__): Handle clang. git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@4950 4407c894-4637-0410-b4f5-ada5f102cad1 commit af9c6a501318354918ef8b64fad847687b8ac214 Author: Jacek Caban mailto:cja...@gmail.com>> Date: Mon Apr 2 07:45:47 2012 + Makefile.am: Added downloadmgr.idl to IDL_SRCS (missing in previous patch) git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@4934 4407c894-4637-0410-b4f5-ada5f102cad1 "svn co http://svn.code.sf.net/p/mingw-w64/code/trunk@4936” gets me something, but it’s hard to tell if it’s what I want. I’d appreciate any help. Thanks, Joe
Re: source code for the 5.16.1.1 release
Hi, 4936 is SVN revision number. After mingw-w64 project had migrated to git I am not quite sure what is the corresponding git commit. -- kmx On 14.8.2015 20:01, Joe Malcolm wrote: First, thanks a lot for your work on Strawberry Perl - it’s made my life quite a bit easier. I am wondering how to find the source code for the "mingw-w64-crt” component of this release. On http://strawberryperl.com/release-notes/5.16.1.1-32bit.html it’s listed as: mingw-w64-crt_2.x_r4936 http://mingw-w64.sourceforge.net/ But r4936 does not seem to be available in the git repository. E.g.: git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 mingw-w64-mingw-w64 gives me a repo which seems to go from 4934 to 4950: commit 9ea33d20a97d5f8812233c2d6682af2461707df1 Author: Ozkan Sezer mailto:seze...@gmail.com>> Date: Tue Apr 10 08:00:51 2012 + _mingw.h (__int128, __SIZEOF_INT128__): Handle clang. git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@4950 4407c894-4637-0410-b4f5-ada5f102cad1 commit af9c6a501318354918ef8b64fad847687b8ac214 Author: Jacek Caban mailto:cja...@gmail.com>> Date: Mon Apr 2 07:45:47 2012 + Makefile.am: Added downloadmgr.idl to IDL_SRCS (missing in previous patch) git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@4934 4407c894-4637-0410-b4f5-ada5f102cad1 "svn co http://svn.code.sf.net/p/mingw-w64/code/trunk@4936” gets me something, but it’s hard to tell if it’s what I want. I’d appreciate any help. Thanks, Joe
Strawberry Perl 5.22.0.1 released
Strawberry Perl 5.22.0.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.22.0.1-32bit.html http://strawberryperl.com/release-notes/5.22.0.1-64bit.html IMPORTANT: considering a good track record of perl core "zero" releases the 5.22.0 is a recommended download from now (in the past we used to recommend waiting for "point-one" release). I would also like to thank our sponsor Enlightened Perl Organisation for resources provided to our project. -- kmx
Strawberry Perl 5.20.2.1 released
Strawberry Perl 5.20.2.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.20.2.1-32bit.html <http://strawberryperl.com/release-notes/5.20.2.1-32bit.html> http://strawberryperl.com/release-notes/5.20.2.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: Installing Alien::ffmpeg, missing pr
Hi, I think your request should be addressed to Alien::MSYS as it IMO delivers tools required for GNU style configure scripts on Windows. Odds are pretty low that these tools will be included in standard strawberry perl. But you can create a RT here: https://rt.cpan.org/Public/Dist/Display.html?Name=Perl-Dist-Strawberry just for future reference (note that there are already some bugs with subject "[Extension Request] ..."). -- kmx On 22.2.2015 16:12, Timm Murray wrote: I'm trying to install Alien::ffmpeg on Strawberry Perl 5.20.1.1 x64. It ends with the output below about missing the "pr" command, as well as yasm/nasm. It appears that several CPAN smoke test reports show the same issue. Any chance of including these in the distribution? Thanks, Timm Murray + sh configure --prefix=C:/STRAWB~1/perl/site/lib/auto/share/dist/Alien-ffmpeg configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found yasm/nasm not found or too old. Use --disable-yasm for a crippled build.
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
Re: Digital signatures missing from latest release and older release has revoked signature
I am sorry but I am not going to sign MSI packages anymore as I have no suitable signing code certificate. I used to use a signing certificate issued by Certum CA (they have Opensource signing program for free) however their obstacles and bureaucracy reached some point at which I was not able to renew the certificate. Certum helpdesk was not very helpful (quite the opposite) which maybe due to the fact that I am a non-paying "customer". Frankly speaking, based on my experience I would rather avoid using their services even as a commercial client. Believe me I wasted a lot of time dealing with this issue and I simply decided to stop. -- kmx On 7.2.2015 6:20, Guitar Hero wrote: I have downloaded two versions from your website. Version 5.18.4.1 shows as revoked signature for k...@cpan.org <mailto:k...@cpan.org>. Version 5.20.1.1 is not digitally signed. 3e47973d81f6cc087a652317e6c0409e343e539a *strawberry-perl-5.18.4.1-32bit.msi ae0d63ab1d0b964c44638c63ddb87d67390b87f7 *strawberry-perl-5.18.4.1-64bit.msi 3566c2cbf891218614e8fd20b72a3b5e9f3a38aa *strawberry-perl-5.20.1.1-32bit.msi 3550ca5837e2494fee1601b3e31b573b5c41e967 *strawberry-perl-5.20.1.1-64bit.msi Will you release a new version that is digitally signed (and valid)? I have a digital signature requirement before I install software. 5.18.2.2 has a valid signature so I am using that version. Thanks
Re: Oracle is included - how about Sybase?
On 1.12.2014 16:23, Matthew Persico wrote: I see that DBD::Oracle is now included in Strawberry. I'd like to see DBD::Sybase also included. Well, I have included Oracle DB driver as it is IMO commercial DB No.1. I am not sure how popular Sybase DB is nowadays and how big is its user base (esp. among potential strawberry perl users). The other think is that my Oracle DB related knowledge is quite good whereas I know literally nothing about Sybase DB. I assume the steps to doing so are: 1) Identify a FREE downloadable client library package for Sybase, a'la Oracle Insta-client Have you done some research in this area? 2) Build using Strawberry One problem is that the make requires interaction. Is it a problem for your automation if the make prompts for input or can you ignore it? Interaction has to be avoided (either by setting proper env variables or passing proper command line params to Makefile.PL/Build.PL). The most important think is that we need DBD::Sybase to be built with gcc/mingw-w64 compiler (quite often various SDK's come only with *.lib libraries suitable for MSVC compiler). And it also matters how many megabytes does DBD::Sybase add to strawberry perl. 3) Sumbit "something" to "someone" in order to include. This, of course, is where I need info. :-) Do I pull down a git, modify and create a pull request somewhere? Is there an FAQ on this I missed? All modules bundled with strawberry perl are built from sources at "release build time". I am not in favor of including packages built by some else. So there must be a functional unattended installation scenarion how to build DBD::Sybase with gcc/mingw-w64 (+ obviously some kind of Sybase client library) And as you might guess the Sybase client library must be available for free and for both 32/64bit MS Windows. Anyway, do not take this e-mail as a promise of any kind :) -- kmx
Re: Redistributing Strawberry Perl
On 24.10.2014 0:50, Daniel Kasak wrote: Hi all. I've managed ( thanks to a developer I hired ) to build Gtk3 libraries and Perl bindings that work with Strawberry Perl. I'm now planning on maintaining the Gtk3 and binding stuff, and hosting Windows binaries. I have a reasonable idea of the legal requirements involved in redistributing open-source stuff, but I'm basically looking for people's blessing to distribute ( at this point ) a large package that includes everything, and call it something like: strawberry-5.20.1-gtk-3.14.3-v1.0.zip. Does anyone have objections to me using the 'strawberry' name? Or any other objections? It is absolutely fine to redistribute strawberry perl providing that your project comply with licenses of individual packages included in strawberry perl. Strawberry perl itself does not introduce any restrictions regarding redistributing/repackaging. As for using "strawberry" in the name of your alternative/experimental perl distribution I am concerned just about end users being confused. Perhaps Adam Kennedy who is in charge of strawberryperl.com domain might have some opinion. The other option for you might be to join strawberry perl project and make your gtk3 distribution available from http://strawberryperl.com/releases.html as we provide "PortableZIP edition + extra PDL related libs" (which is basically strawberry perl + bunch of math related external libraries). In the medium term, I hope to be able to break things out into individual packages that people can install on top of an existing Strawberry Perl installation ( or maybe even have this work rolled into Stawberry Perl ), but at this point, I have one large installation directory and a repeatable process to build things. On the topic of packaging things ... if anyone knows an easy solution for making these individual packages under mingw & msys, that will help a lot. I had a look at the tools used in the build of Camelbox ( another such project, but targeting Gtk2 ), and from what I could tell, the process was basically doing a comparison of the filesystem before & after installing each package to determine what files should be added to a package. Is this the only way of doing this? If it is, I guess I'll go down that path too ... I have uploaded to github - https://github.com/StrawberryPerl/build-extlibs - our scripts we use for building external libraries bundled with strawberry perl. They are very simple and not much clever (as you guess doing a comparison of the file system before & after installing each package) but they work. Maybe you will find interesting https://github.com/Alexpux/MINGW-packages - which is much more sophisticated (and also includes scripts+patches to build gtk3). -- kmx
Strawberry Perl 5.18.4.1 released
Strawberry Perl 5.18.4.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.18.4.1-32bit.html http://strawberryperl.com/release-notes/5.18.4.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org/> for resources provided to our project. -- kmx
Strawberry Perl 5.20.1.1 released
Strawberry Perl 5.20.1.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.20.1.1-32bit.html <http://strawberryperl.com/release-notes/5.20.1.1-32bit.html> http://strawberryperl.com/release-notes/5.20.1.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: statically linked Strawberry Perl for use with PerlApp?
On 23.6.2014 16:56, Robert Eden wrote: On 6/23/2014 5:47 AM, sisyph...@optusnet.com.au wrote: -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 That should work! I'll let the list know how it goes (and if it works with PerlApp) Just keep in mind that you probably do not want "static perl" you probably just want to use "-static-libgcc -static-libstdc++" compiler flags (which might introduce another unwanted side effects). Try to run dmake like this: dmake "BUILDOPTEXTRA=-static-libgcc -static-libstdc++" I have not tried it, this is just my guess. As Gabor mentioned if you want to try to build your custom Strawberry Perl start here: https://metacpan.org/pod/distribution/Perl-Dist-Strawberry/script/perldist_strawberry -- kmx
Strawberry Perl 5.20.0.1 released
Strawberry Perl 5.20.0.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.20.0.1-32bit.html <http://strawberryperl.com/release-notes/5.20.0.1-32bit.html> http://strawberryperl.com/release-notes/5.20.0.1-64bit.html I would also like to thank our sponsor AuditSquare.com <https://auditsquare.com> for resources provided to our project. -- kmx
Re: Strawberry Perl MSI installer
On 15.5.2014 20:27, Jan Dubois wrote: On Thu, May 15, 2014 at 11:10 AM, Chris Marshall wrote: Not familiar with MSI details but I hope any changes won't be a problem for SPP which is useful because it *doesn't* require special permissions---just enough to create the folder... This has nothing to do with MSI, but with putting a directory on the PATH to which the user has write access. Essentially all scripting languages do this to allow the user to install additional modules easily, but security companies like to put out alerts about this... With ZIP and Portable it completely in user's hand how he|she created destination directory and with what filesystem permissions. This will not change. It is not a new issue; here is the ActiveState position about the same issue with ActivePerl: https://community.activestate.com/node/9199 TL;DR: The default is more convenient for most users; it is trivial for users to apply more restrictive ACLs if they are bothered about it. Yes, exactly the same issue and I guess also the solution will be the same :) Thanks. -- kmx
Strawberry Perl MSI installer
Hi, We have many reports related to problems with installing strawberry perl via MSI installer. Like troubles with installing on non-C: drive, troubles with installing on a machine completely without C: drive, some permission related issues etc. I have prepared redesigned version of MSI (it is 5.19.11.4) and made it available at http://strawberryperl.com/beta/ - visually it looks exactly as the old installer but guts changed a lot. If you have experienced in past any troubles with MSI installer or if you can test it on a unusual machine (like one with system drive D: without drive C:) or if you can test it on a box with some unusual UAC settings - please get the latest beta from URL above and check if the MSI installer works for you. In case of troubles run: c:\anydir> msiexec /l*vx install.log /i strawberry-perl-5.19.11.4-64bit.msi and send me install.log (off-list) The second issue is related to our highly respected sponsor https://auditsquare.com as their security checker (even FREE version) reports a security warning related to strawberry perl installation. In short it says that PATH contains directories (c:\strawberry\c\bin c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by too wide group of users (built-in Users or even Authenticated Users). We currently do not explicitly set any filesystem ACL therefore C:\strawberry directory gets some ACL inherited from C:\ which is probably mostly fine but might be a trouble if you choose another directory (or another drive) which parent dir has some strange and/or unexpected ACL. I feel that our MSI should probably set some filesystem ACL on C:\strawberry (which is supported by WiX Toolset we use for MSI creation) but I am not sure what it should be (e.g. Administrators+SYSTEM/FullControl, Users/Read+Execute ?). Any ideas or preferably experiences with building MSI are welcome. -- kmx
Re: StrawberryPerl and the OpenSSL "heartbleed" bug
On 17.4.2014 19:26, matthew.pers...@lazard.com wrote: I have my own local directories that cpanp knows about. I'm going to try and put _Math-Pari-2.01080605_patched.tar.g_z in one of them and see if I cannot coax cpanp to build locally. If not, Illl cpanm from your repo. Can I assume that when 5.18.2.3 or whatever the next version is, the patch will be in the main distribution? Yes -- kmx
Re: Run an external program and capture its output
On 17.4.2014 13:49, John Emmas wrote: On 17/04/2014 11:34, sisyph...@optusnet.com.au wrote: . 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 Wow, I'm amazed! I've been programming on Windows for nearly 30 years, yet I never encountered this problem before. Nevertheless you're absolutely right Rob. Placing the word "perl" at the start of my command line solved the problem! Sadly, the fix suggested by that article didn't work in my case - but no matter, at least I've got a solution now. One more question - is there a way to obtain the Windows version information using a perl script? For example, can I obtain the value of WINVER somehow? Check https://metacpan.org/pod/Win32#Win32::GetOSDisplayName and https://metacpan.org/pod/Win32#Win32::GetOSVersion -- kmx
Re: Run an external program and capture its output
On 17.4.2014 9:24, Sergei Steshenko wrote: From: kmx To: win32-vanilla@perl.org Sent: Thursday, April 17, 2014 10:14 AM Subject: Re: Run an external program and capture its output On 17.4.2014 8:47, John Emmas wrote: Firstly, please forgive me if this isn't the right place for asking this question. I tried a couple of programmer's forums but up to now, my question hasn't even gained one answer! And yet it seems like a simple (and probably very common) requirement. I'm hoping that someone here will take pity on me! I've been using Strawberry perl for about 6 months and I'm generally happy with it. The one thing I just can't seem to make it do is to run an external program and capture that program's output to a file. I came across perl's 'system' command. Let's say I add these lines to a perl script:- @my_command = ( "the_exe_name", "arg1", "arg2", "etc" ); system(@my_command); If I now open a DOS window and run the perl script, sure enough, it runs 'the_exe_name'. And if my exe produces any text output I can see that output in my DOS window.. Suppose my perl script is called "my_perl_script.pl". If I try to redirect its text output (like this) something interesting happens:- my_perl_script.pl > output.txt The above seems to work in Windows 7. However, it doesn't work in Windows 8 or Windows XP. In both cases, the file "output.txt" does get created. And in both cases I no longer see the exe's output text in my DOS window (i.e. as if it's getting redirected to the file). But at the end of the process (in both cases) output.txt will be an empty file. :-( My next thought was to handle any redirection within the actual perl script - i.e. @my_command = ( "the_exe_name", "arg1", "arg2", "etc" ">", "output.txt" ); system(@my_command); Unfortunately, that doesn't seem to work either (again, it always creates an empty file). Is there a way to achieve this using Strawberry perl? Or am I making some rookie mistake here? Admittedly I'm not very experienced with perl but I'm amazed that such a simple task seems to defeat it :-( Try: my $output = `the_exe_name arg1 arg2`; Or have a look at https://metacpan.org/pod/IPC::Run3 use IPC::Run3; my $output; run3(["the_exe_name", "arg1", "arg2", "etc"], undef, \$output); -- kmx FWIW, the my $output = `the_exe_name arg1 arg2`; way is to capture just STDOUT - _not_ STDERR. Regardless of OS. I do not remember what 'IPC::Run3' WRT STDERR. IPC::Run3 works AFAIK like this: run3(["the_exe_name", "arg1", "arg2", "etc"], undef, \$std_out_and_err); or run3(["the_exe_name", "arg1", "arg2", "etc"], undef, \$std_out, \$std_err); -- kmx
Re: Run an external program and capture its output
On 17.4.2014 8:47, John Emmas wrote: Firstly, please forgive me if this isn't the right place for asking this question. I tried a couple of programmer's forums but up to now, my question hasn't even gained one answer! And yet it seems like a simple (and probably very common) requirement. I'm hoping that someone here will take pity on me! I've been using Strawberry perl for about 6 months and I'm generally happy with it. The one thing I just can't seem to make it do is to run an external program and capture that program's output to a file. I came across perl's 'system' command. Let's say I add these lines to a perl script:- @my_command = ( "the_exe_name", "arg1", "arg2", "etc" ); system(@my_command); If I now open a DOS window and run the perl script, sure enough, it runs 'the_exe_name'. And if my exe produces any text output I can see that output in my DOS window.. Suppose my perl script is called "my_perl_script.pl". If I try to redirect its text output (like this) something interesting happens:- my_perl_script.pl > output.txt The above seems to work in Windows 7. However, it doesn't work in Windows 8 or Windows XP. In both cases, the file "output.txt" does get created. And in both cases I no longer see the exe's output text in my DOS window (i.e. as if it's getting redirected to the file). But at the end of the process (in both cases) output.txt will be an empty file. :-( My next thought was to handle any redirection within the actual perl script - i.e. @my_command = ( "the_exe_name", "arg1", "arg2", "etc" ">", "output.txt" ); system(@my_command); Unfortunately, that doesn't seem to work either (again, it always creates an empty file). Is there a way to achieve this using Strawberry perl? Or am I making some rookie mistake here? Admittedly I'm not very experienced with perl but I'm amazed that such a simple task seems to defeat it :-( Try: my $output = `the_exe_name arg1 arg2`; Or have a look at https://metacpan.org/pod/IPC::Run3 use IPC::Run3; my $output; run3(["the_exe_name", "arg1", "arg2", "etc"], undef, \$output); -- kmx
Re: StrawberryPerl and the OpenSSL "heartbleed" bug
Excellent, I have put patched version at http://strawberryperl.com/package/kmx/perl-modules-patched/Math-Pari-2.01080605_patched.tar.gz Simply run: cpanm http://strawberryperl.com/package/kmx/perl-modules-patched/Math-Pari-2.01080605_patched.tar.gz -v -- kmx On 16.4.2014 22:50, Jan Dubois wrote: On Wed, Apr 16, 2014 at 1:46 PM, kmx wrote: The reason is simple - it does not build anymore as it is not able to find required pari source tarball at ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/ Here is a quick-and-dirty patch to work around this (but hard-wires you to 2.1.7): --- a/utils/Math/PariBuild.pm +++ b/utils/Math/PariBuild.pm @@ -301,7 +301,7 @@ EOP } $base_url = "ftp://$host$dir";; -my @extra_chdir = qw(OLD); +my @extra_chdir = qw(OLD/2.1); print "Getting GP/PARI from $base_url\n"; eval { Cheers, -Jan
Re: StrawberryPerl and the OpenSSL "heartbleed" bug
The reason is simple - it does not build anymore as it is not able to find required pari source tarball at ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/ Try: cpanm Math::Pari -v ... Getting GP/PARI from ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/ Not in this directory, now chdir('OLD')... Did not find any file matching /((?:.*\/)?pari\W*(?!2\.(?:[3-9]|\d\d+)\.)(\d+\.\d+\.\d+).*\.t(?:ar\.)?gz)$/ via FTP ... Not in this directory, trying `ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/OLD/'... Did not find any file matching /((?:.*\/)?pari\W*(?!2\.(?:[3-9]|\d\d+)\.)(\d+\.\d+\.\d+).*\.t(?:ar\.)?gz)$/ via FTP. ... In January 2014 the installation worked so that's why it is included in 5.18.2.1 and not in 5.18.2.2 Another trouble with Math::Pari (in fact it is a trouble with underlying pari library) is that it has never built correctly with 64bit compiler on MS Windows. -- kmx On 16.4.2014 22:07, matthew.pers...@lazard.com wrote: Any reason why 5.18.2.2 excludes Math::Pari? Math::Pari is used (a couple of levels down) by Net::SFTP. Net::SFTP is the reason I converted TO Strawberry about three weeks ago. Please advise... -- Matthew O. Persico Lazard 30 Rockefeller Plaza New York, NY 10112 212 632 6136 From: kmx To: win32-vanilla@perl.org Date: 04/16/2014 01:31 AM Subject: Re: StrawberryPerl and the OpenSSL "heartbleed" bug --- Olivier, You can try updated strawberry perl from: _ __http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-32bit.msi__ __http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-64bit.msi__ __http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-32bit.zip__ __http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-64bit.zip__ __http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-32bit-portable.zip__ __http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-64bit-portable.zip_ -- kmx On 15.4.2014 0:36, kmx wrote: Hi, you can get updated openssl binaries from: - _http://strawberryperl.com/package/kmx/64_libs/gcc47-2014Q1/_ - _http://strawberryperl.com/package/kmx/32_libs/gcc47-2014Q1/_ I am considering releasing strawberry perl 5.18.2.2 (with new openssl) before the end of April. -- kmx On 12.4.2014 20:45, Olivier Mengué wrote: Hi, You have probably heard of the now famous "heartblead" bug of the OpenSSL library. _http://heartbleed.com/_ StrawberryPerl is bundled with a binary of the OpenSSL library so I'm wondering if StrawberryPerl is affected by the bug. I had a look at the release notes of StrawberryPerl to look for the version number of the OpenSSL and all versions of StrawberryPerl since at least 5.16.0.1 have an OpenSSL in the range affected by the heartbleed bug. It would be helpful to have an official statement from the StrawberryPerl team regarding this issue and to display it prominently on the StrawberryPerl.com page. Olivier Mengué _https://metacpan.org/author/DOLMEN_
Re: StrawberryPerl and the OpenSSL "heartbleed" bug
Olivier, You can try updated strawberry perl from: http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-32bit.msi http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-64bit.msi http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-32bit.zip http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-64bit.zip http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-32bit-portable.zip http://strawberryperl.com/download/5.18.2.2/strawberry-perl-5.18.2.2-64bit-portable.zip -- kmx On 15.4.2014 0:36, kmx wrote: Hi, you can get updated openssl binaries from: - http://strawberryperl.com/package/kmx/64_libs/gcc47-2014Q1/ - http://strawberryperl.com/package/kmx/32_libs/gcc47-2014Q1/ I am considering releasing strawberry perl 5.18.2.2 (with new openssl) before the end of April. -- kmx On 12.4.2014 20:45, Olivier Mengué wrote: Hi, You have probably heard of the now famous "heartblead" bug of the OpenSSL library. http://heartbleed.com/ StrawberryPerl is bundled with a binary of the OpenSSL library so I'm wondering if StrawberryPerl is affected by the bug. I had a look at the release notes of StrawberryPerl to look for the version number of the OpenSSL and all versions of StrawberryPerl since at least 5.16.0.1 have an OpenSSL in the range affected by the heartbleed bug. It would be helpful to have an official statement from the StrawberryPerl team regarding this issue and to display it prominently on the StrawberryPerl.com page. Olivier Mengué https://metacpan.org/author/DOLMEN
Re: StrawberryPerl and the OpenSSL "heartbleed" bug
Hi, you can get updated openssl binaries from: - http://strawberryperl.com/package/kmx/64_libs/gcc47-2014Q1/ - http://strawberryperl.com/package/kmx/32_libs/gcc47-2014Q1/ I am considering releasing strawberry perl 5.18.2.2 (with new openssl) before the end of April. -- kmx On 12.4.2014 20:45, Olivier Mengué wrote: Hi, You have probably heard of the now famous "heartblead" bug of the OpenSSL library. http://heartbleed.com/ StrawberryPerl is bundled with a binary of the OpenSSL library so I'm wondering if StrawberryPerl is affected by the bug. I had a look at the release notes of StrawberryPerl to look for the version number of the OpenSSL and all versions of StrawberryPerl since at least 5.16.0.1 have an OpenSSL in the range affected by the heartbleed bug. It would be helpful to have an official statement from the StrawberryPerl team regarding this issue and to display it prominently on the StrawberryPerl.com page. Olivier Mengué https://metacpan.org/author/DOLMEN
Strawberry Perl 5.18.2.1 released
Strawberry Perl 5.18.2.1 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.18.2.1-32bit.html http://strawberryperl.com/release-notes/5.18.2.1-64bit.html I would also like to thank our sponsor AuditSquare.com <https://auditsquare.com> for resources provided to our project. -- kmx
Re: DBD::mysql 4.025
try: C:\> cpanm DBD::mysql --configure-args="--mysql_config=mysql_config" --verbose --force -- kmx On 28.12.2013 16:19, Paul Durden wrote: The DBD::mysql CPAN module has been updated to 4.025 to address many Windows related issues. The DBD::mysql version packaged with Strawberry Perl v5.18.1.1 is 4.023. I have had no luck in building the 4.025 myself, and was wondering if anyone has a binary install, or knows if the next Strawberry Perl maintenance release will include the newer version. Thanks, Paul
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. 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? -- kmx
Re: rebuilding OpenSSL under Strawberry Perl
I can reproduce your failure. My first build was 64bit and went fine. I am afraid it is an issue with openssl-fips and/or openssl configure script or makefile. -- kmx On 10.9.2013 18:37, Thomas J Pinkl wrote: On 09/10/2013 04:35 AM, kmx wrote: openssl-fips-2.0.5 seems to build fine for me, here is how you can do it: kmx, thanks for taking the time to help with this. My build is failing at step 6 (see below). 1/ download MSYS environment from http://sourceforge.net/projects/perlmingw/files/MSYS%20Environment%20for%20End%20Users/ 2/ unpack standard-msys-2022.7z into - e.g. c:\dev\msys 3/ make sure you have gcc compiler from strawberry perl in your PATH - e.g. c:\strawberry\c\bin 4/ unpack sources openssl-fips-2.0.5.tag.gz into e.g. c:\dev\openssl-fips-2.0.5 openssl-1.0.1e.tar.gz into c:\dev\openssl-1.0.1e 5/ start c:\dev\msys\msys.bat 6/ in MSYS prompt $ cd /c/dev/openssl-fips-2.0.5 $ ./Configure mingw64 shared --prefix=/c/dev/output $ make $ make install $ cd /c/dev/openssl-1.0.1e $ ./Configure mingw64 shared fips --with-fipsdir=/c/dev/output --prefix=/c/dev/output $ make depend $ make $ make install_sw NOTE: for 32bit Windows use "./Configure mingw ..." instead of "./Configure mingw64 ..." I am using "mingw" since I'm on a 32-bit system. I used "/c/OpenSSL" as the prefix and fipsdir. The "make" for openssl-1.0.1e fails for me with: make[4]: Entering directory `/c/dev/openssl-1.0.1e' Creating library file: libcrypto.dll.a libcrypto.a(uplink.o):uplink.c:(.text+0x30): multiple definition of `OPENSSL_Uplink' c:/OpenSSL/lib/fipscanister.o:uplink.c:(.text+0x3ac20): first defined here libcrypto.a(uplink-x86.o):uplink-x86.s:(.data+0x0): multiple definition of `OPENSSL_UplinkTable' c:/OpenSSL/lib/fipscanister.o:uplink-x86.s:(.data+0x140): first defined here c:/sbperl/c/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/bin/ld.exe: c:/OpenSSL/lib/fipscanister.o: bad reloc address 0xa in section `.text.unlikely' collect2: ld returned 1 exit status make[4]: *** [link_a.cygwin] Error 1 make[4]: Leaving directory `/c/dev/openssl-1.0.1e' make[3]: *** [do_cygwin-shared] Error 2 make[3]: Leaving directory `/c/dev/openssl-1.0.1e' make[2]: *** [libcrypto.dll.a] Error 2 make[2]: Leaving directory `/c/dev/openssl-1.0.1e' make[1]: *** [shared] Error 2 make[1]: Leaving directory `/c/dev/openssl-1.0.1e/crypto' make: *** [build_crypto] Error 1 Any ideas? 7/ take the results from c:\dev\output In strawberry perl we do a bit of kung-fu with *.a renaming libcrypto.dll.a >> libeay32.a libssl.dll.a >> libssleay32.a libssl.dll.a >> libssl32.a (yes, duplicity) + we completely drop static libraries libcrypto.a, libssl.a -- kmx What are the .dll.a files then?
Re: rebuilding OpenSSL under Strawberry Perl
Thomas, openssl-fips-2.0.5 seems to build fine for me, here is how you can do it: 1/ download MSYS environment from http://sourceforge.net/projects/perlmingw/files/MSYS%20Environment%20for%20End%20Users/ 2/ unpack standard-msys-2022.7z into - e.g. c:\dev\msys 3/ make sure you have gcc compiler from strawberry perl in your PATH - e.g. c:\strawberry\c\bin 4/ unpack sources openssl-fips-2.0.5.tag.gz into e.g. c:\dev\openssl-fips-2.0.5 openssl-1.0.1e.tar.gz into c:\dev\openssl-1.0.1e 5/ start c:\dev\msys\msys.bat 6/ in MSYS prompt $ cd /c/dev/openssl-fips-2.0.5 $ ./Configure mingw64 shared --prefix=/c/dev/output $ make $ make install $ cd /c/dev/openssl-1.0.1e $ ./Configure mingw64 shared fips --with-fipsdir=/c/dev/output --prefix=/c/dev/output $ make depend $ make $ make install_sw NOTE: for 32bit Windows use "./Configure mingw ..." instead of "./Configure mingw64 ..." 7/ take the results from c:\dev\output In strawberry perl we do a bit of kung-fu with *.a renaming libcrypto.dll.a >> libeay32.a libssl.dll.a >> libssleay32.a libssl.dll.a >> libssl32.a (yes, duplicity) + we completely drop static libraries libcrypto.a, libssl.a -- kmx
Re: rebuilding OpenSSL under Strawberry Perl
On 6.9.2013 2:41, Thomas J Pinkl wrote: On 09/01/2013 03:01 PM, kmx wrote: In that case here is the build script: http://svn.ali.as/cpan/users/kmx/strawberry_packs_devel/build/go-build.sh Do you patch the standard openssl 1.0.1e distribution in order to get it to build under the MinGW provided with Strawberry Perl? There are no patches, strawberry perl is bundleded with genuine 1.0.1e version (I always run openssl test suite and nothing fails) I'm still unsuccessful in building openssl 1.0.1e with fips 2.0.5. I'll try and let you know. -- kmx
Re: rebuilding OpenSSL under Strawberry Perl
In that case here is the build script: http://svn.ali.as/cpan/users/kmx/strawberry_packs_devel/build/go-build.sh -- kmx On 31.8.2013 16:44, Curtis Jewell wrote: I'll help out here: kmx: I think he needs the command lines/batch files used for the process when you created the build, and the procedure to set up a build environment - that way, he can follow the procedures used in http://www.openssl.org/docs/fips/UserGuide-2.0.pdf chapter 4 to do the rebuild. Mr. Pinkl: (Once you get that information from kmx) In Strawberry Perl's case, the Microsoft Windows directions in that file are the wrong direction to go - the build environment for Strawberry Perl is more 'Unix/Linux' style than Microsoft Windows style (Strawberry Perl specifically uses gcc instead of Microsoft Visual C++, for example.) --Curtis On Sat, Aug 31, 2013, at 3:47, kmx wrote: On 30.8.2013 18:57, Thomas J Pinkl wrote: I need to rebuild OpenSSL 1.0.1e to include the FIPS object module, under Strawberry Perl 5.16.x for both 32-bit and 64-bit platforms. Can anyone point me to the procedure that was used to build the non-FIPS capable OpenSSL 1.0.1e under Strawberry Perl? Here are build logs for both 32/64bit openssl builds: http://pastebin.com/MQPWc6iu http://pastebin.com/wYTWEcPw What exactly are you looking for? -- kmx -- Curtis Jewell http://strawberryperl.com/ p...@csjewell.fastmail.us http://csjewell.dreamwidth.org/ Strawberry Perl for Windows betas: http://strawberryperl.com/beta/
Re: rebuilding OpenSSL under Strawberry Perl
On 30.8.2013 18:57, Thomas J Pinkl wrote: I need to rebuild OpenSSL 1.0.1e to include the FIPS object module, under Strawberry Perl 5.16.x for both 32-bit and 64-bit platforms. Can anyone point me to the procedure that was used to build the non-FIPS capable OpenSSL 1.0.1e under Strawberry Perl? Here are build logs for both 32/64bit openssl builds: http://pastebin.com/MQPWc6iu http://pastebin.com/wYTWEcPw What exactly are you looking for? -- kmx
Strawberry Perl 5.18.1.1 released
First I would like to thank our new sponsor AuditSquare.com <https://auditsquare.com> for resources provided to our project. Strawberry Perl 5.18.1.1 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.18.1.1-32bit.html http://strawberryperl.com/release-notes/5.18.1.1-64bit.html -- kmx
Re: msys for SP
On 5.6.2013 3:50, sisyph...@optusnet.com.au wrote: Hi, Is there a Strawberry distro for download that includes the msys shell ? AFAIK there is none. Presumably, msys is readily available as a separate download, so I guess it's no big deal if there isn't ... just wondering. 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/ -- kmx
Strawberry Perl 5.18.0.1 released
Strawberry Perl 5.18.0.1 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.18.0.1-32bit.html http://strawberryperl.com/release-notes/5.18.0.1-64bit.html -- kmx
Re: Portable config information
On 4.5.2013 20:12, Chris Marshall wrote: I would like to make some module configuration files work with strawberry perl portable. Currently, the paths saved in config files are absolute which means if SPP is moved to another location, things break. I see that Portable provides something like this. Is there a standard way to do the same for other configuration files and/or other modules? BTW, the specific files of interest at the moment are Prima::Config and PDL::Config. Technically it is possible but IMO not easily. There is no general portable magic, each thing you want to make portable needs some hacking. There 2 crucial modules: https://metacpan.org/release/Portable https://metacpan.org/release/Portable-Dist For let us say PDL::Config you need to 1/ create something like Portable::PDLConfig (probably very close to already existing Portable::Config) 2/ small changes to Portable::Dist To make it clear I am not an author of the original idea I only somehow understand how it works. On the other hands I am a maintainer of both Portable::Dist + Portable so if you/we manage to put together some reasonable patches I can release it (+include into the next portable strawberry) -- kmx
Re: make.exe?
On 26.4.2013 19:23, Brian Manning wrote: On Fri, Apr 26, 2013 at 10:13 AM, Andrew Pennebaker wrote: Strawberry Perl is my go-to package for getting a sane development environment in Windows. Just today, I was trying to install App::Ack on an old Dell, and found Strawberry Perl very helpful in the process. Compiling modules with C extensions like ack requires make<https://github.com/petdance/ack2/issues/255>, which doesn't work so well in Windows. Try using 'dmake' to install App::Ack. IIRC it's already included with Strawberry. Exactly, there is 'dmake' for installation like C:\any_pkg_root_dir> perl Makefile.PL ... C:\any_pkg_root_dir> dmake test ... C:\any_pkg_root_dir> dmake install On top of that there is also GNU make bundled with strawberry perl as 'gmake' (it is intended for special purposes) -- kmx
Re: The shebang supplied with starberryperl/bin/cpan doesn't work with Git Bash
It should be IMO fixed in 5.16.2.2 Please have a look athttps://rt.cpan.org/Public/Bug/Display.html?id=82837 -- kmx
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
On 4.4.2013 21:46, Michiel Beijen wrote: On Thu, Apr 4, 2013 at 9:25 PM, kmx wrote: C:\strawberry\cpan\build\Log-Log4perl-1.40-XYO4Rb\blib\lib/Log/Log4perl/Resurrector.pm line 28.t/053Resurrect.t . Dubious, test returned 253 (wstat 64768, 0xfd00) You have to downgrade File::Temp to version 0.22 then it works nice with strawberry 5.17.10 Thanks, this works indeed! What File::Temp version do you have on your Debian box? On Debian I have 0.23, which does not seem to cause any trouble there. Should I file a bug report for File::Temp? It is either a bug in File::Temp or Log::Log4perl is using File::Temp in a way that is not supported on all platforms. But yes, probably start an RT for File::Temp BTW: the same behaviour on strawberry perl 5.16.1 -- kmx
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
On 4.4.2013 16:46, Michiel Beijen wrote: Hi kmx, On Wed, Apr 3, 2013 at 10:25 PM, kmx wrote: So, 32bit strawberry perl 5.18.x will be built with USE_64_BIT_INT You can test 5.17.10 beta (32bit+USE_64_BIT_INT) from: http://strawberryperl.com/beta/ (MSI+ZIP+Portable) Great! I'm using it right now to test some modules. I got this error on Log::Log4perl 053Resurrect.t - and only on Windows, not on my Debian perl 5.17.10. Could it have anything to do with the build options for this StrawberryPerl? Deep recursion on subroutine "Log::Log4perl::Resurrector::resurrector_fh" at C:\strawberry\cpan\build\Log-Log4perl-1.40-XYO4Rb\blib\lib/Log/Log4perl/Resurrector.pm line 70. Deep recursion on subroutine "File::Temp::tempfile" at C:\strawberry\cpan\build\Log-Log4perl-1.40-XYO4Rb\blib\lib/Log/Log4perl/Resurrector.pm line 28.t/053Resurrect.t . Dubious, test returned 253 (wstat 64768, 0xfd00) You have to downgrade File::Temp to version 0.22 then it works nice with strawberry 5.17.10 What File::Temp version do you have on your Debian box? -- kmx
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
So, 32bit strawberry perl 5.18.x will be built with USE_64_BIT_INT You can test 5.17.10 beta (32bit+USE_64_BIT_INT) from: http://strawberryperl.com/beta/ (MSI+ZIP+Portable) -- kmx
Re: Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
On 13.3.2013 23:14, sisyph...@optusnet.com.au wrote: -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. Thanks for feedback. 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. 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 strawberry perl. (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. 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. As for COW I am gonna follow perl core default behaviour. -- kmx
Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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. 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?) -- kmx
Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
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. 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?) -- kmx
Strawberry Perl 5.16.3.1 + 5.14.4.1 released
Strawberry Perl 5.16.3.1 + 5.14.4.1 are available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.16.3.1-32bit.html http://strawberryperl.com/release-notes/5.16.3.1-64bit.html http://strawberryperl.com/release-notes/5.14.4.1-32bit.html http://strawberryperl.com/release-notes/5.14.4.1-64bit.html -- kmx
Strawberry Perl 5.16.2.2 released
Strawberry Perl 5.16.2.2 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.16.2.2-32bit.html http://strawberryperl.com/release-notes/5.16.2.2-64bit.html -- kmx
Re: DBD::Oracle
Hi Lyle, The main reason is probably no demand for such a thing (+ other reasons like complicated build procedure, license agreements for Oracle stuff ...) If you are willing to spend some time on testing I can include DBD::Oracle (in "ActivePerl way") in the next strawberry perl release. I have prepared pre-build distributions - for Strawberry Perl 5.16.2.x (32/64bit), linked with Oracle Instant Client 11.2.0.3.0: http://strawberryperl.com/package/kmx/perl-modules-par/DBD-Oracle-1.56-MSWin32-x86-multi-thread-5.16.2.par http://strawberryperl.com/package/kmx/perl-modules-par/DBD-Oracle-1.56-MSWin32-x64-multi-thread-5.16.2.par You can install them into strawberry perl simply by running: c:\> pip You also need Oracle Instant Client 11.2.0.3.0 + put it in your PATH (it might also work with other versions) - no SDK, just Client It would be nice if you can install + test the above mentioned *.par with a real Oracle DB. -- kmx On 20.1.2013 20:18, Lyle wrote: Hi All, I noticed Strawberry didn't come with DBD::Oracle. What was the reason for that? I've just built DBD::Oracle on Windows 7 with Perl 5.16.2 x64 with all tests passing. I added how I did it as comments to the Pythan article here: http://www.pythian.com/news/5/dbdoracle-and-windows-64bit/#comment-1385661 I can see that this has been in RT for a while: https://rt.cpan.org/Public/Bug/Display.html?id=48796 ActivePerl ships with DBD::Oracle, although you have to download the client libraries yourself. This would appear to be the only feasible way forward. As it stands people are either having to: 1) Download the DBD::Oracle sources, download the client libraries, compile and build. This is time consuming, especially if you want the tests to pass as the documentation isn't clear. 2) Download the ActivePerl ppm, download the client libraries, hope you have the right client libraries and the path set right so it works. If Strawberry Perl came with DBD::Oracle and clear instructions on how to install the client libraries, or better still, the installer had an option for downloading and installing them for you, I think that would be best. Thoughts? Lyle
Re: [OT] Problem building gd-2.0.35 library
On 4.12.2012 8:53, Sisyphus wrote: Hi, Obviously way OT for this list - but I see that Strawberry ships with gd-2.0.35, so I'm hoping someone here has faced (and solved) the problem I've struck. See enclosed patch I am using when building gd for strawberry perl - I am not saying it will fix your troubles :) Some notes: - I am not sure why but for some reason I do not enable pthreads although I have them - there is IIRC some mismatch in timestamps so before running ./configure I call: touch -r Makefile.am config.* Makefile.* configure* aclocal.* -- kmx diff -r -u -w --strip-trailing-cr /z/strawberry_libs/build/_wrk_2012Q4_/gd-2.0.35/Makefile.in /z/strawberry_libs/build/../patches/gd-2.0.35/Makefile.in --- /z/strawberry_libs/build/_wrk_2012Q4_/gd-2.0.35/Makefile.in 2007-04-23 14:57:51 + +++ /z/strawberry_libs/build/../patches/gd-2.0.35/Makefile.in 2009-11-16 11:04:00 + @@ -345,7 +345,7 @@ include_HEADERS = gd.h gdfx.h gd_io.h gdcache.h gdfontg.h gdfontl.h gdfontmb.h gdfonts.h gdfontt.h entities.h lib_LTLIBRARIES = libgd.la libgd_la_SOURCES = gd.c gdfx.c gd_security.c gd_gd.c gd_gd2.c gd_io.c gd_io_dp.c gd_gif_in.c gd_gif_out.c gd_io_file.c gd_io_ss.c gd_jpeg.c gd_png.c gd_ss.c gd_topal.c gd_wbmp.c gdcache.c gdfontg.c gdfontl.c gdfontmb.c gdfonts.c gdfontt.c gdft.c gdhelpers.c gdhelpers.h gdkanji.c gdtables.c gdxpm.c jisx0208.h wbmp.c wbmp.h -libgd_la_LDFLAGS = -version-info 2:0:0 $(XTRA_LDFLAGS) +libgd_la_LDFLAGS = -version-info 2:0:0 $(XTRA_LDFLAGS) -no-undefined libgd_la_LIBADD = $(LTLIBICONV) LDADD = ./libgd.la $(LIBICONV) all: config.h diff -r -u -w --strip-trailing-cr /z/strawberry_libs/build/_wrk_2012Q4_/gd-2.0.35/configure /z/strawberry_libs/build/../patches/gd-2.0.35/configure --- /z/strawberry_libs/build/_wrk_2012Q4_/gd-2.0.35/configure 2007-04-23 14:57:52 + +++ /z/strawberry_libs/build/../patches/gd-2.0.35/configure 2009-11-25 13:19:46 + @@ -728,8 +728,8 @@ # Identity of this package. PACKAGE_NAME='GD' PACKAGE_TARNAME='gd' -PACKAGE_VERSION='2.0.34' -PACKAGE_STRING='GD 2.0.34' +PACKAGE_VERSION='2.0.35' +PACKAGE_STRING='GD 2.0.35' PACKAGE_BUGREPORT='http://bugs.libgd.org' ac_unique_file="gd.c" @@ -2126,7 +2126,7 @@ GDLIB_MAJOR=2 GDLIB_MINOR=0 -GDLIB_REVISION=34 +GDLIB_REVISION=35 GDLIBNAME=gd #Expanded by tests later in this file. TBB 2.0.26 #2.0.28: GIF is standard now. Doesn't depend on anything else, @@ -2425,7 +2425,7 @@ # Define the identity of the package. PACKAGE='gd' - VERSION='2.0.34' + VERSION='2.0.35' cat >>confdefs.h <<_ACEOF @@ -23128,7 +23128,7 @@ echo $ECHO_N "(cached) $ECHO_C" >&6 else ac_check_lib_save_LIBS=$LIBS -LIBS="-lXpm -lX11 $LIBS" +LIBS="-lXpm $LIBS" cat >conftest.$ac_ext <<_ACEOF /* confdefs.h. */ _ACEOF @@ -23184,7 +23184,7 @@ { echo "$as_me:$LINENO: result: $ac_cv_lib_Xpm_XpmReadFileToXpmImage" >&5 echo "${ECHO_T}$ac_cv_lib_Xpm_XpmReadFileToXpmImage" >&6; } if test $ac_cv_lib_Xpm_XpmReadFileToXpmImage = yes; then - LIBS="-lXpm -lX11 $LIBS" + LIBS="-lXpm $LIBS" FEATURES="GD_XPM $FEATURES" cat >>confdefs.h <<\_ACEOF
Re: Build perl with mingw-w64
... Than I try to build with next command line: dmake INST_DRV=$DRV INST_TOP=$PREFIX_WIN/opt CCHOME=$MINGWHOME_WIN WIN64=undef ... From using '$VARIABLE' I assume you are not running dmake from standard command prompt (cmd.exe) which makefile.mk expects Try to: - make sure that you have 'dmake', 'gcc' & co. in your PATH - start command prompt (cmd.exe) - from command prompt: dmake INST_DRV=%DRV% INST_TOP=%PREFIX_WIN/opt% CCHOME=%MINGWHOME_WIN% WIN64=undef -- kmx
Strawberry Perl 5.16.2.1 released
Strawberry Perl 5.16.2.1 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.16.2.1-32bit.html http://strawberryperl.com/release-notes/5.16.2.1-64bit.html -- kmx
Strawberry Perl 5.14.3.1 released
Strawberry Perl 5.14.3.1 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.14.3.1-32bit.html http://strawberryperl.com/release-notes/5.14.3.1-64bit.html -- kmx
Re: Strawberry Perl dies on Vista after August 2012 Windows Update
On 20.8.2012 15:21, Andrew Murphy (home) wrote: Hi Have Strawberry Perl 5.16 with Windows Vista – all worked fine. 1) Applied August Microsoft Security patches from Windows Update Perl wouldn’t run. 2) Googled – no mention of it. 3) Uninstalled Stawberry Perl, and removed C:\strawberry Installed latest version 5.16.1 Rebooted, Perl still wouldn’t run. 4) Went into Windows update, and backed out the security updates Rebooted, Perl now works fine (well, except for all the CPAN modules I have to re-install) (Sorry, if were Unix, I could run truss to find out what the problem was, but on Windows, I don’t know where to start) So it looks like something in the Windows Updates is causing a problem with Perl Andrew Unfortunately I do not have any Win Vista available for testing, however on my Win7 box with latest updates both 32/64bit 5.16.1.1 work fine. Are you trying to use 32 or 64 bit strawberry perl? Are you running any antivirus sw? -- kmx
Strawberry Perl 5.16 & kaspersky antivirus
Does anybody experienced any troubles when installing Strawberry Perl 5.16.0.1 or 5.16.1.1 on a Windows box with kaspersy AV? I mean a trouble like this: https://rt.cpan.org/Ticket/Display.html?id=78457 -- kmx
Re: Strawberry Perl 5.16.1.1 released
On 10.8.2012 14:28, Ricardo Signes wrote: * kmx [2012-08-10T08:01:08] Strawberry Perl 5.16.1.1 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) Fantastic, I'll upgrade immediately! :-) Thanks for your work on this! Thanks to *you* Ricardo and your p5p team, you made 5.16.1, I am just a packager :) -- kmx
Strawberry Perl 5.16.1.1 released
Strawberry Perl 5.16.1.1 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.16.1.1-32bit.html http://strawberryperl.com/release-notes/5.16.1.1-64bit.html -- kmx
Re: HELP???
On 13.6.2012 21:48, Gabor Szabo wrote: > ... > > kmx, have you talked to the maintainer of Win32::GUI ? > As I can see he https://metacpan.org/author/ROBERTMAY has not > released anything in the last 3 years. No, I have just posted couple of RTs (without any response from the author). To be honest Win32::API is quite complex piece of code so not an easy job to be a maintainer. -- kmx
Re: HELP???
> I don't use a Perl GUI very much, but if Strawberry Perl is installed, then > launching cpan in a terminal then installing Win32-GUI should work. You will very likely (especially when using 64bit perl) want to install patched version from: http://strawberryperl.com/package/kmx/perl-modules-patched/Win32-GUI-1.06_patched3.tar.gz On strawberry perl simply by running "pip" command: c:\somedir> pip http://strawberryperl.com/package/kmx/perl-modules-patched/Win32-GUI-1.06_patched3.tar.gz -- kmx
Strawberry Perl 5.16.0.1 released
Strawberry Perl 5.16.0.1 is available at http://strawberryperl.com/releases.html (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.16.0.1-32bit.html http://strawberryperl.com/release-notes/5.16.0.1-64bit.html -- kmx
Re: 32bit strawberry perl with -Duse64bitint
> I already see: > > .IF "$(USE_ITHREADS)" == "define" > ARCHNAME !:= $(ARCHNAME)-thread > .ENDIF > > So I guess it's just a matter of adding after that something like: > > .IF "$(USE_64_BIT_INT)" == "define" > ARCHNAME !:= $(ARCHNAME)-64int > .ENDIF You are nearly right, I have ended up with http://svn.ali.as/cpan/trunk/Perl-Dist-Strawberry/share/perl-5.16-x86-64int/diffs_for_info_only/makefile.mk.diff Check http://strawberryperl.com/beta/ for the latest "64int" build -- kmx
Re: 32bit strawberry perl with -Duse64bitint
> One thing I noticed is that $Config{archname} still reports > 'MSWin32-x86-multi-thread'. > I think it should probably differentiate itself from -Uuse64bitint > builds, though I'm not sure of the rules in this regard (if there are any). > Perhaps something like 'MSWin32-x86-multi-thread-64int' - but if there > are no rules, then I reckon *you* get to choose. > Well, I have changed in config_H.gc: #define ARCHNAME "MSWin32-x86-64int" but it is obviously the wrong place and the wrong string - I should revert it. It seems that some hacking/patching in win32/makefile.mk can fix this. > Looking forward to the arrival of 'MSWin32-x86-multi-thread-64int-ld' ;-) > you mean -Duselongdouble? -- kmx
Re: 32bit strawberry perl with -Duse64bitint
On 16.5.2012 5:00, Sisyphus wrote: > - Original Message - From: "kmx" > To: > Sent: Wednesday, May 16, 2012 7:37 AM > Subject: 32bit strawberry perl with -Duse64bitint > >> On 28.4.2012 5:13, Sisyphus wrote: >>> ... >>> kmx, have you already been working on building a 32-bit SP with >>> -Duse64bitint ? >> >> Now available at http://strawberryperl.com/beta/ (only Portable edition >> based on perl-5.16.0-RC1) >> >> Applied patches to config.gc and config_H.gc are here: >> http://svn.ali.as/cpan/trunk/Perl-Dist-Strawberry/share/perl-5.16-x86-64int/diffs_for_info_only/ >> > > Excellent !! > I'll try this out as soon as I get a chance. > > Is the dbm/gdbm/ndbm stuff critical to the build of a -Duse64bitint perl ? > (I'll probably wait until 5.16.0 is released, whereupon I intend to try > building such a perl myself, using the mingw.org compiler (gcc-4.5.2). It > doesn't have any of the dbm/gdbm/ndbm stuff, afaik.) Of course *dbm thinks are absolutely unrelated to -Duse64bitint. I have just taken the changes we do in "standard" strawberry perl + applied additional changes related to -Duse64bitint. In http://svn.ali.as/cpan/trunk/Perl-Dist-Strawberry/share/perl-5.16/diffs_for_info_only/ you can see what changes are "standard" in strawberry perl. I think you can easily distinguish what has to be patched for -Duse64bitint. -- kmx
32bit strawberry perl with -Duse64bitint
On 28.4.2012 5:13, Sisyphus wrote: > ... > kmx, have you already been working on building a 32-bit SP with > -Duse64bitint ? Now available at http://strawberryperl.com/beta/ (only Portable edition based on perl-5.16.0-RC1) Applied patches to config.gc and config_H.gc are here: http://svn.ali.as/cpan/trunk/Perl-Dist-Strawberry/share/perl-5.16-x86-64int/diffs_for_info_only/ -- kmx
strawberry perl 5.16 BETA available for testing
Check http://strawberryperl.com/beta/ Any feedback welcome. -- kmx
Re: problems with strawberry perl portable and cpan
> kmx, have you already been working on building a 32-bit SP with > -Duse64bitint ? Not yet but we already have some hackery applied on win32/config_H.gc and win32/config.gc - I expect that couple of more hacking in these two files can make use64bitint possible. I can do more on this after I release strawberry 5.16.0 (approx the end of May). -- kmx
Re: strawberry perl - bug in wrapper batch files
On 27.4.2012 19:07, René Staffen wrote: > Hi, > it seems that some mails got lost. > Here is it again: > > Original-Nachricht > Betreff: strawberry perl - bug in wrapper batch files > Datum: Thu, 26 Apr > An: win32-vanilla@perl.org2012 15:34:44 +0200 > Von: "René Staffen > > Hi, > iam using strawberry perl and i got some problems with the wrapper batch > files. > when installing new modules they are placed into > strawvberry-folder/perl/*site* > also the bat files. > > The problem is, that the wrapper batchs allways explicitly try to call > perl from their own directory via "%~dp0perl.exe" instead simply use > "perl.exe" > > in site sub dir there is no perl.exe of course. > this seems to be a bug. Yes it is a known bug in portable 5.12.x try portable 5.14.x which does not suffer from this issue. -- kmx
Re: problems with strawberry perl portable and cpan
> That appears to be from the 32bit SP. > Could you send the 64bit perl -V as well? d:\perl64>perl -V Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x64-multi-thread uname='Win32 strawberryperl 5.14.2.1-portable #1 Tue Nov 22 19:46:20 2011 x64' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.4.7', gccosandvers='' intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++.exe', ldflags ='-s -L"D:\perl64\perl\lib\CORE" -L"D:\perl64\c\lib"' libpth=D:\perl64\c\lib D:\perl64\c\x86_64-w64-mingw32\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl514.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"D:\perl64\perl\lib\CORE" -L"D:\perl64\c\lib"' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Built under MSWin32 Compiled at Nov 22 2011 19:58:55 %ENV: PERL_JSON_BACKEND="JSON::XS" PERL_YAML_BACKEND="YAML" @INC: D:/perl64/perl/site/lib D:/perl64/perl/vendor/lib D:/perl64/perl/lib . > How difficult would it be for me to build > a 32bit SP with use64bit stuff enabled? Currently the build engine is under complete reconstruction. How quickly do you need it? -- kmx
Re: problems with strawberry perl portable and cpan
> BTW, it would be useful if the release notes on the > web site also included the output from 'perl -V' OK, I will consider it (FYI: I have already on my TODO list missing checksums for released ZIPs) > or is there already somewhere to get that (without having > to install SP first)? You can ask me :) d:\perl32>perl -V Summary of my perl5 (revision 5 version 14 subversion 2) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='Win32 strawberryperl 5.14.2.1-portable #1 Tue Nov 22 18:24:29 2011 i386' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.4.7', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++.exe', ldflags ='-s -L"D:\perl32\perl\lib\CORE" -L"D:\perl32\c\lib"' libpth=D:\perl32\c\lib D:\perl32\c\i686-w64-mingw32\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl514.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"D:\perl32\perl\lib\CORE" -L"D:\perl32\c\lib"' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Built under MSWin32 Compiled at Nov 22 2011 18:32:55 %ENV: PERL_JSON_BACKEND="JSON::XS" PERL_YAML_BACKEND="YAML" @INC: D:/perl32/perl/site/lib D:/perl32/perl/vendor/lib D:/perl32/perl/lib
Re: problems with strawberry perl portable and cpan
On 25.4.2012 16:26, "René Staffen" wrote: > Hi, > I hope this is the right mailing list. it was linked from > http://strawberryperl.com/support.html but its name does not sound related > for me. Please inform me, it iam wrong. > > Beside this doubts here is my Problem: > i use a portable edition of strawberry but i got problems with cpan. > cpan always gives errors if perl is not present at the folder there i first > used portable perl. > The errors are of kind 'file not found' because cpan looks in the old > directory > eg: >> Das System kann den angegebenen Pfad nicht finden. >> ADAMK/DBD-SQLite-1.35.tar.gz >> E:\Development\Scripte\strawberry-perl-5.12.3.0-portable__\c\bin\dmake.exe >> -- NOT OK > the current path is c:\strawberry-perl but may change because i also use this > installation from USB-Stick > > i allready tried to delete the cpan/build folder but with no success. > > i allready installed many things so i do not want to start from clean > installation > > Any hints? Please try strawberry perl portable 5.14.2.1 from release page <http://strawberryperl.com/releases.html> - portable 5.12.3 is buggy. -- kmx
Re: Vanilla Perl and 5.16.0
Hi again, my quick test with 5.15.8 I have mentioned in my previous post was probably too quick (I wrongly set up 64bit build), here are updated results: 1/ tests results for 32bit-gcc - crash (segfault in UNIX words) in re/reg_eval_scope.t - crash (segfault in UNIX words) in op/fork.t - tests hang up in ../cpan/CPANPLUS-Dist-Build/t/02_CPANPLUS-Dist-Build.t The crashes are "new" the hang up I have already experienced with 5.14.x - http://www.nntp.perl.org/group/perl.perl5.porters/2011/04/msg171428.html and 2/ tests results for 64bit-gcc - crashes (more than one) in re/reg_eval_scope.t - crash in op/fork.t - some strange error during op/taint.t (maybe something broken on my Win7 box) - one failed test in ../ext/Pod-Html/t/cache.t 3/ pointer-to-int and int-to-pointer casting warnings with 64bit-gcc "Only" approx 60 occurrences in the following files: - pp_pack.c (3x) - RealPPPort.xs (1x) - POSIX.xs (1x) - Socket.xs (7x) - Storable.xs (more than 40) 4/ in order to have NDBM_File + ODBM_File in strawberry perl we need these two extra files in perl core tarball: ext/NDBM_File/hints/MSWin32.pl ext/ODBM_File/hints/MSWin32.pl mentioned in my RT https://rt.perl.org/rt3/Ticket/Display.html?id=71680 (please consider including them in 5.16.0) -- kmx
Re: Vanilla Perl and 5.16.0
Hi Ricardo, I have done just a quick test building 5.15.8 with gcc 4.6.2 (gcc candidate to be included in the next strawberry perl release, gcc binaries built by Mark Dootson). The good news is that it is possible to build working perl binaries with both 32/64bit gcc (I am using c-runtime from mingw-w64.sf.net project). 1/ tests results for 32bit-gcc - crash (segfault in UNIX words) in re/reg_eval_scope.t - crash (segfault in UNIX words) in op/fork.t - tests hang up in ../cpan/CPANPLUS-Dist-Build/t/02_CPANPLUS-Dist-Build.t The crashes are "new" the hang up I have already experienced with 5.14.x - http://www.nntp.perl.org/group/perl.perl5.porters/2011/04/msg171428.html and 2/ tests results for 64bit-gcc - crashes (more than one) in re/reg_eval_scope.t - crash in op/fork.t - some strange error during op/taint.t - but test suite finished with theese results: Test Summary Report --- op/fork.t (Wstat: 0 Tests: 25 Failed: 1) Failed test: 16 op/taint.t (Wstat: 0 Tests: 791 Failed: 2) Failed tests: 1, 391 ../cpan/CGI/t/tmpdir.t (Wstat: 0 Tests: 9 Failed: 0) TODO passed: 3-9 ../dist/Storable/t/compat01.t (Wstat: 1536 Tests: 6 Failed: 6) Failed tests: 1-6 Non-zero exit status: 6 ../dist/Storable/t/file_magic.t (Wstat: 256 Tests: 79 Failed: 1) Failed test: 13 Non-zero exit status: 1 ../dist/Storable/t/malice.t (Wstat: 512 Tests: 404 Failed: 2) Failed tests: 13, 132 Non-zero exit status: 2 ../ext/PerlIO-scalar/t/scalar.t (Wstat: 65280 Tests: 76 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 79 tests but ran 76. ../ext/Pod-Html/t/cache.t (Wstat: 256 Tests: 10 Failed: 1) Failed test: 8 Non-zero exit status: 1 Files=2327, Tests=526521, 9710 wallclock secs (55.39 usr + 5.12 sys = 60.51 CPU) Result: FAIL dmake: Error code 141, while making 'test' 3/ pointer-to-int and int-to-pointer casting warnings with 64bit-gcc Not sure how much you are aware of Windows (I guess that rather less than more) but there is "a thing" with 64 bit MS Windows that sizeof pointer is 8 bytes but sizeof int (or long) is just 4 bytes which might obviously cause some troubles. The gcc-4.6.2 compiler I have used has by default turned on warnings: - cast from pointer to integer of different size [-Wpointer-to-int-cast] - cast to pointer from integer of different size [-Wint-to-pointer-cast] During perl build on 64bit Windows there are many warnings of these kind (by many I mean approx 500) -- kmx
Re: 5.12.3 portable / Tk installation
On 23.11.2011 12:06, Ch Lamprecht wrote: Hello, there is a problem with Tk-804.030 build failing using strawberry 5.12.3 portable. The following test-report gives details (Win7). I see the same issue trying to build Tk on WinXP 32 / strawberry 5.12.3 portable. http://www.cpantesters.org/cpan/report/cd91ab56-6bf3-1014-831b-9f0412cd2d3c Tk builds fine using the standard strawberry installation: Hi, yes, strawberry 5.12.3 portable has a bug related to $Config{libpth} which causes Tk installation failure. Solutions: 1/ for 5.12.3 try patch mentioned here http://www.mail-archive.com/win32-vanilla@perl.org/msg00343.html 2/ for 5.14.2 try the latest portable beta/RC from here http://strawberryperl.com/package/kmx/p5.14.2.1-RC/ -- kmx
Re: CPAN::Reporter and strawberry perl portable
On 20.11.2011 19:58, chm wrote: It would be very convenient if Strawberry Perl (portable and regular editions) included modules needed for CPAN Testers submissions. Whenever I set up a new strawberry perl portable (SPP) sandbox for testing, I always have to redo the install and update to support the new metabase and CPAN::Reporter. One issue with running CPAN::Reporter for test reports with SPP is that the default directory seems to be set to C:\.cpanreporter rather than a folder in the SPP root directory. Cheers, Chris Hi Chris, there are basically 2 kind of issues 1/ troubles with Strawberry Portable Perl (SPP) 2/ bugs in CPAN::Reporter As for 1/ there were a lot of changes during the last week(s) in SPP; please take the latest beta from http://strawberryperl.com/package/kmx/p5.14.2.1-RC/ for your testing (I know that you prefer to have 5.12.x but we are currently focused only on fixing 5.14 builds). In the latest SPP the issue with C:\.cpanreporter should not happen any more as in SPP the "pseudo" home directory is located in "\data" directory (providing that the module in question uses File::HomeDir - which is the case of CPAN::Reporter). The following works for me with the latest beta of SPP: Let us have portable strawberry perl in z:\portable4testing z:\portable4testing> cpan -fi Task::CPAN::Reporter z:\portable4testing> mkdir z:\portable4testing\data\.cpanreporter\ z:\portable4testing> metabase-profile -o z:\portable4testing\data\.cpanreporter\metabase_id.json z:\portable4testing> cpan cpan> o conf init test_report cpan> o conf commit cpan> q Now the troubles marked 2/ (CPAN::Reporter related) */ there are some failing tests - on the latest SPP 5.14.2.1-beta t/03_config_file.t + t/70_darwin_move_config.t - which is the reason why you need "-fi" for installation */ in theory it should be enough to run "cpan> o conf init test_report" just after Task::CPAN::Reporter installation (it calls "metabase-profile" command automatically) however on my Windows box it stucks at this point: Would you like to run 'metabase-profile' now to create 'Z:\portable4testing\data\.cpanreporter\metabase_id.json'? [y] Running [Z:\PORTAB~1\perl\bin\metabase-profile.BAT --output Z:\portable4testing\data\.cpanreporter\metabase_id.json --email k...@cpan.org --secret 123456789]... Enter full name: ... where I am not able to enter the requested full name. Which is IMHO an issue in CPAN::Reporter not SPP. This is the reason for creating z:\portable4testing\data\.cpanreporter\metabase_id.json manually before running "cpan> o conf init test_report". */ the good news is that CPAN::Reporter does use File::HomeDir (not $ENV{HOME} or $ENV{USERPROFILE}) which makes it portable-perl-friendly To sum up: if you take the latest Strawberry Portable Perl beta it should "somehow" work + I might be a good idea to report remaining CPAN::Reporter issues to proper place. -- kmx
Re: gcc for building Perl on WinXP
Hi Rob, Just getting to it now. (I know Chris has already established that the pthreads suport builds fine using his small patch to pthread.h. I'm building PDL-2.4.9_009, also with pthreads support as provided by 2), above - and also with Chris's amendment to pthread.h.) First thing I noticed with this Strawberry distro is that, as with most (all ?) Strawberry distros, there's no gfortran compiler. This means that the Slatec and Minuit parts of PDL won't get built. That's old news, and not all that critical - but I thought I should mention it anyway ;-) I know about that :) Apart from: http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip We have also prepared other PDL handy stuff - like: http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gfortran4.4.7-pre_2001.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_gsl-1.15-bin_2004.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_fftw-2.1.5-bin_20110506.zip It is only about decision how fat should strawberry perl be. Anyway you can unzip them into one directory and have a go. Apart from that, all looks good Unrelated to PDL, but the latest mpfr library (version 3.1.0) should build with TLS (Thread Local Storage) by default and straight out of the box. The version of the mpfr library that ships with Strawberry (version 3.0.1) was not built with TLS - which probably means that you didn't ask for it (--enable-TLS) when building the library. Mind you, I haven't checked that --enable-TLS will work for mpfr-3.0.1 on Windows, but 3.1.0 certainly provided TLS for me ... and without my asking.) No big deal - just thought I'd mention. On threaded perls, that TLS capability can be handy for Math::MPFR. Thanks for this notice, I will try to use --enable-TLS by the next mpfr-3.1+ rebuild (according ./configure --help it seems not to be available in 3.0.1). I noticed, too, that the mpc library that ships with Strawberry hasn't been built to accommodate the complex.h types (double _Complex and long double _Complex). From a perl point of view, this hardly matters at all because there's no way to natively pass these types to or from perl. I did slap together a Math::Complex_C module that wraps the complex.h types and functions, and thereby provides a gateway to passing these types to Math::MPC, but I doubt that anyone makes use of this capability anyway. Besides, Math::Complex_C can sometimes fail a test or two, generally because of compiler bugs (mainly in the form of incorrectly implemented functions). To enable this should I pass some extra option to mpc configure/make? -- kmx
Re: gcc for building Perl on WinXP
Yes, "dmake clean" did the trick. Thanks. -- kmx On 7.11.2011 22:32, Chris Marshall wrote: I just realized what might have happened. You'll need to do a dmake clean and then a complete build from scratch to ensure that old copies of the various files are not being used (some of these are generated at the configure stage). On Mon, Nov 7, 2011 at 4:20 PM, Chris Marshall wrote: Are you sure this is the latest PDL git from sf.net? The error here looks like something that has already been fixed as of CPAN developers release 2.4.9_008 according to the PDL Release_Notes. --Chris On Mon, Nov 7, 2011 at 4:07 PM, kmx wrote: Chris, that sounds great, however my attempt ended up with: C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils\xsubpp -typemap C:\strawberry\perl\lib\ExtUtils\typemap -typemap typemap Core.xs Core.xsc&& C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e mv -- Core.xsc Core.c Could not find a typemap for C type 'PDL_Long *' in Core.xs -- kmx On 7.11.2011 20:40, Chris Marshall wrote: I just pushed a new PDL git with a fix for the perl vs POSIX threads namespace/implementation collision. You should be able to build with the unedited pthread.h now --Chris On Sun, Nov 6, 2011 at 5:58 PM, chmwrote: dmake test passed all except the known problem with t/pthreadBarf.t. Also, I think we can fix the breakage in pthread.h by doing the undef in our pdlmagic file that is including pthread.h. Cheers, Chris On 11/6/2011 5:40 PM, chm wrote: I got it to work with the following: Add after the POSIX Threads comment block in pthread.h: #ifdef PTHREAD_CREATE_JOINABLE #undef PTHREAD_CREATE_JOINABLE #endif in order to remedy the fact that perl has added a macro with the same value. If the pthread one is not already defined then the perl one is---but this breaks the w32 pthreads include file. Then set the parameters in perldl.conf to WITH_POSIX_THREADS =>1, POSIX_THREADS_INC =>undef, # '-I/usr/pthread/include' POSIX_THREADS_LIBS =>'-lpthread', # '-L/usr/pthread -lpthreadGC2' It is building away as I type. Will let you know how dmake test comes out --Chris On 11/6/2011 4:31 PM, chm wrote: Hi kmx- The detection for the pthread library is currently broken. To build PDL with pthreads you'll need to explicitly set the values of WITH_POSIX_THREADS, POSIX_THREADS_INC, and POSIX_THREADS_LIBS where the comment indicate what worked for my strawberry perl install was: WITH_POSIX_THREADS =>undef, POSIX_THREADS_LIBS =>'-LC:/chm/strawberry/pthreads/lib -lpthreadGC2', POSIX_THREADS_INC =>'-IC:/chm/strawberry/pthreads/include', and the C:/chm/strawberry/pthreads contained the pthreads install location. I'm actually working on the detection code this evening so that if a pthread library is in the correct location it would be detected and used. I'll give your library a build try this evening if I can. Cheers, Chris On 11/6/2011 4:14 PM, kmx wrote: Chris and/or Rob, could you please try the following: 1/ take http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip 2/ take http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip (unzip into the same dir as 1/) 3/ try to build PDL with pthreads support My quick test failed during PDL installation (but it was really a quick shot) Any feedback welcome -- kmx On 3.11.2011 14:13, Chris Marshall wrote: We've tested the PDL pthread support with "POSIX Threads (pthreads) for Win32" at http://sourceware.org/pthreads-win32/ . It is nice because it allows PDL computations to make use of multicore processors for calculations. Always nice to see those factors of 2X, 4X, 6X, or more in speedup --Chris On Wed, Nov 2, 2011 at 9:30 PM, Sisyphus wrote: - Original Message - From: "kmx" As for the future gcc-4.6.2 toolchain there is also an interesting question about including pthreads or winpthreads support as PDL is AFAIK somohow able to handle threads this way (not sure if this is valid for Win32) Yes, pthreads works with PDL on Win32. There's a crash in one of PDL's pthread test scripts that needs to be sorted out, but the basic functionality seems to be fine. Cheers, Rob - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1411 / Virus Database: 2092/4000 - Release Date: 11/06/11
Re: gcc for building Perl on WinXP
Chris, that sounds great, however my attempt ended up with: C:\strawberry\perl\bin\perl.exe C:\strawberry\perl\lib\ExtUtils\xsubpp -typemap C:\strawberry\perl\lib\ExtUtils\typemap -typemap typemap Core.xs > Core.xsc && C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e mv -- Core.xsc Core.c Could not find a typemap for C type 'PDL_Long *' in Core.xs -- kmx On 7.11.2011 20:40, Chris Marshall wrote: I just pushed a new PDL git with a fix for the perl vs POSIX threads namespace/implementation collision. You should be able to build with the unedited pthread.h now --Chris On Sun, Nov 6, 2011 at 5:58 PM, chm wrote: dmake test passed all except the known problem with t/pthreadBarf.t. Also, I think we can fix the breakage in pthread.h by doing the undef in our pdlmagic file that is including pthread.h. Cheers, Chris On 11/6/2011 5:40 PM, chm wrote: I got it to work with the following: Add after the POSIX Threads comment block in pthread.h: #ifdef PTHREAD_CREATE_JOINABLE #undef PTHREAD_CREATE_JOINABLE #endif in order to remedy the fact that perl has added a macro with the same value. If the pthread one is not already defined then the perl one is---but this breaks the w32 pthreads include file. Then set the parameters in perldl.conf to WITH_POSIX_THREADS => 1, POSIX_THREADS_INC => undef, # '-I/usr/pthread/include' POSIX_THREADS_LIBS => '-lpthread', # '-L/usr/pthread -lpthreadGC2' It is building away as I type. Will let you know how dmake test comes out.... --Chris On 11/6/2011 4:31 PM, chm wrote: Hi kmx- The detection for the pthread library is currently broken. To build PDL with pthreads you'll need to explicitly set the values of WITH_POSIX_THREADS, POSIX_THREADS_INC, and POSIX_THREADS_LIBS where the comment indicate what worked for my strawberry perl install was: WITH_POSIX_THREADS => undef, POSIX_THREADS_LIBS => '-LC:/chm/strawberry/pthreads/lib -lpthreadGC2', POSIX_THREADS_INC => '-IC:/chm/strawberry/pthreads/include', and the C:/chm/strawberry/pthreads contained the pthreads install location. I'm actually working on the detection code this evening so that if a pthread library is in the correct location it would be detected and used. I'll give your library a build try this evening if I can. Cheers, Chris On 11/6/2011 4:14 PM, kmx wrote: Chris and/or Rob, could you please try the following: 1/ take http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip 2/ take http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip (unzip into the same dir as 1/) 3/ try to build PDL with pthreads support My quick test failed during PDL installation (but it was really a quick shot) Any feedback welcome -- kmx On 3.11.2011 14:13, Chris Marshall wrote: We've tested the PDL pthread support with "POSIX Threads (pthreads) for Win32" at http://sourceware.org/pthreads-win32/ . It is nice because it allows PDL computations to make use of multicore processors for calculations. Always nice to see those factors of 2X, 4X, 6X, or more in speedup --Chris On Wed, Nov 2, 2011 at 9:30 PM, Sisyphus wrote: - Original Message - From: "kmx" As for the future gcc-4.6.2 toolchain there is also an interesting question about including pthreads or winpthreads support as PDL is AFAIK somohow able to handle threads this way (not sure if this is valid for Win32) Yes, pthreads works with PDL on Win32. There's a crash in one of PDL's pthread test scripts that needs to be sorted out, but the basic functionality seems to be fine. Cheers, Rob - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1411 / Virus Database: 2092/4000 - Release Date: 11/06/11
Re: gcc for building Perl on WinXP
Chris and/or Rob, could you please try the following: 1/ take http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip 2/ take http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip (unzip into the same dir as 1/) 3/ try to build PDL with pthreads support My quick test failed during PDL installation (but it was really a quick shot) Any feedback welcome -- kmx On 3.11.2011 14:13, Chris Marshall wrote: We've tested the PDL pthread support with "POSIX Threads (pthreads) for Win32" at http://sourceware.org/pthreads-win32/ . It is nice because it allows PDL computations to make use of multicore processors for calculations. Always nice to see those factors of 2X, 4X, 6X, or more in speedup --Chris On Wed, Nov 2, 2011 at 9:30 PM, Sisyphus wrote: - Original Message - From: "kmx" As for the future gcc-4.6.2 toolchain there is also an interesting question about including pthreads or winpthreads support as PDL is AFAIK somohow able to handle threads this way (not sure if this is valid for Win32) Yes, pthreads works with PDL on Win32. There's a crash in one of PDL's pthread test scripts that needs to be sorted out, but the basic functionality seems to be fine. Cheers, Rob
Re: gcc for building Perl on WinXP
Mark, As you probably know strawberry perl is using sezero's gcc toolchain build since approx April 2010. We use "nearly exactly" the original sezero's gcc 4.4.x toolchain - there are basically 2 things we have changed 1/ sezero's gcc builds ignore /include dir when searching for *.h files which is not good as we put a lot of stuff into c:\strawberry\c\include - fortunately the fix is just a little change to build scripts not to gcc code (more details at http://sourceforge.net/tracker/?func=detail&aid=2886331&group_id=202880&atid=983354) 2/ we have one more header: glext/glxext.h Upgrading strawberry perl to sezero's gcc-4.5.x (which works well with latest wxWidget, right?) is feasible as Ozkan has done a really great job (carefully selected patches, nicely prepared, easily to rebuild). The only thing as regards strawberry perl is that we need to rebuild with gcc-4.5.x also all external libraries (20-30 packages). That's the point where I am in doubts whether to go 4.4.x >> 4.5.x or directly 4.4.x >> 4.6.x The biggest (the only) disadvantage of gcc-4.6.x is that Ozkan have currently no plans making gcc-4.6.x build (I have asked him a couple of days ago) - so with gcc-4.6.x we loose all comfort we have now with his gcc-4.4.x/4.5.x builds -- kmx On 2.11.2011 18:04, Mark Dootson wrote: Hi, At mingw-w64 Oskan Sezer (sezero) has updated his release of gcc 4.5.4 including latest patches. This solves my wxWidgets (c++) issues ( and general c++ exception problems for many other things I expect). It should also solve the Windows XP CRT issue which caused strawberry to stick with gcc 4.4.3 for Win32 - I haven't tested on XP yet (Oskan only updated it today) but I've tested the relevant patch for other builds so it should work fine. It comes with gfortran. No expectations of Oskan of course, but given Oskan's record of updating his releases and ease of using his source patches + buildscripts yourself if you wish, this looks like a favourite base for a Perl gcc dist. Mark On 02/11/2011 16:46, Chris Marshall wrote: It would really simplify things for win32 PDL if an easy, 1-click addition for gfortran were available. We're spending a lot of development time working around the lack of a fortran compiler on win32 perls. Since gcc includes one, it is more of a packaging and distribution issue than one of existence. Cheers, Chris On Sun, Oct 30, 2011 at 3:52 PM, Karel Miko wrote: In preparing the next Strawberry release you've no doubt noticed that mingw-w64 32bit version cannot build a working Perl after gcc version 4.4.3 on Windows XP. Yes, in fact it was during the last week when we have found out (with help of BinGOs and Ranguard via IRC) that gcc-4.4.7 and 4.6.1 (not only with mingw-w64 runtime but also with mingw.org's runtime) produce perl binaries that crash on Windows XP. For strawberry perl 5.14.2.0 we have decided to use: - on 32 bit version gcc-4.4.3 (with slightly old mingw-w64 runtime) http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-20100123-kmx-v3.zip - on 64 bit version gcc-4.4.7(prereleae) (with mingw-w64 runtime 1.0.1) http://strawberryperl.com/package/kmx/64_gcctoolchain/mingw64-w64-gcc4.4.7(pre)_20111014.zip Commit 180422 to the 4.6 branch of gcc fixes the problem - I've cross compiled my own 32bit 4.6.2 release (the tagged 4.6.2 release includes this fix) which compiles a working Perl 5.14.2 on Windows XP. Many thanks , this is a valuable piece of information for me as I was in doubts where to start reporting/discussing the issue, now it is clear. For my own use, I need to move to 4.6.2 as 4.4.7 cannot compile wxWidgets 2.9.x branch. As a side benefit I also get an up to date v2 mingw-w64 crt. I'll be publishing source, patches and build instructions at http://perlmingw.sourceforge.net/ (plus, of course, the compiled releases). The patches are just the minimum necessary from sezero build and TDM GCC builds to get a working dist. Just a thought, but it might be nice if we had a sort of 'standard' gcc for Perl on Windows. Why not. As for my opinion concerning gcc toolchain included in strawberry perl: - we would strongly prefer to use mingw-w64 (not mingw.org) runtime for both 32/64bit - we have no special preference as for the gcc version (but versions like gcc-X.Y.0 are perhaps too "in development" for us) - we need gcc toolchain supporting/include and/lib directories in search paths (without explicit -I or -L options) - we would appreciate gcc toolchain with frotran (maybe a kind of addon or extra package) as it comes handy to PDL guys using strawberry Anyhow, I think you could just backport the fix to the current 4.4.7 branch. But, for what it is worth, Strawberry users will be unable to compile wxWidgets 2.9.x branches (without some patching at lea
Re: gcc for building Perl on WinXP
For the strawberry perl we have both gcc + fortran packs 32bit: http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gcc4.4.7-pre_2001.zip http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gfortran4.4.7-pre_2001.zip 64bit: http://strawberryperl.com/package/kmx/64_gcctoolchain/mingw64-w64-gcc4.4.7-pre_2001.zip http://strawberryperl.com/package/kmx/64_gcctoolchain/mingw64-w64-gfortran4.4.7-pre_2001.zip src code + build scripts: http://strawberryperl.com/package/kmx/gcctoolchain_src/mingw64-src-gcc4.4.7-pre_2001.tar But it is still old gcc-4.4.7 (with backported 4.6.2-rev180422 fix to avoid WinXP crashes) that does not handle well wxWidgets as Mark stated below. As for the future gcc-4.6.2 toolchain there is also an interesting question about including pthreads or winpthreads support as PDL is AFAIK somohow able to handle threads this way (not sure if this is valid for Win32) -- kmx On 2.11.2011 17:46, Chris Marshall wrote: It would really simplify things for win32 PDL if an easy, 1-click addition for gfortran were available. We're spending a lot of development time working around the lack of a fortran compiler on win32 perls. Since gcc includes one, it is more of a packaging and distribution issue than one of existence. Cheers, Chris On Sun, Oct 30, 2011 at 3:52 PM, Karel Miko wrote: In preparing the next Strawberry release you've no doubt noticed that mingw-w64 32bit version cannot build a working Perl after gcc version 4.4.3 on Windows XP. Yes, in fact it was during the last week when we have found out (with help of BinGOs and Ranguard via IRC) that gcc-4.4.7 and 4.6.1 (not only with mingw-w64 runtime but also with mingw.org's runtime) produce perl binaries that crash on Windows XP. For strawberry perl 5.14.2.0 we have decided to use: - on 32 bit version gcc-4.4.3 (with slightly old mingw-w64 runtime) http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-20100123-kmx-v3.zip - on 64 bit version gcc-4.4.7(prereleae) (with mingw-w64 runtime 1.0.1) http://strawberryperl.com/package/kmx/64_gcctoolchain/mingw64-w64-gcc4.4.7(pre)_20111014.zip Commit 180422 to the 4.6 branch of gcc fixes the problem - I've cross compiled my own 32bit 4.6.2 release (the tagged 4.6.2 release includes this fix) which compiles a working Perl 5.14.2 on Windows XP. Many thanks , this is a valuable piece of information for me as I was in doubts where to start reporting/discussing the issue, now it is clear. For my own use, I need to move to 4.6.2 as 4.4.7 cannot compile wxWidgets 2.9.x branch. As a side benefit I also get an up to date v2 mingw-w64 crt. I'll be publishing source, patches and build instructions at http://perlmingw.sourceforge.net/ (plus, of course, the compiled releases). The patches are just the minimum necessary from sezero build and TDM GCC builds to get a working dist. Just a thought, but it might be nice if we had a sort of 'standard' gcc for Perl on Windows. Why not. As for my opinion concerning gcc toolchain included in strawberry perl: - we would strongly prefer to use mingw-w64 (not mingw.org) runtime for both 32/64bit - we have no special preference as for the gcc version (but versions like gcc-X.Y.0 are perhaps too "in development" for us) - we need gcc toolchain supporting/include and/lib directories in search paths (without explicit -I or -L options) - we would appreciate gcc toolchain with frotran (maybe a kind of addon or extra package) as it comes handy to PDL guys using strawberry Anyhow, I think you could just backport the fix to the current 4.4.7 branch. But, for what it is worth, Strawberry users will be unable to compile wxWidgets 2.9.x branches (without some patching at least) OK, I take it as your "gcc upgrade" request - we will probably aim at gcc-4.6.2 + mingw-w64 runtime (v2 or latest v2RC) However, currently the release candidates for strawberry 5.14.2.0 are IMHO too good to let them fall on the floor. I think that the updated gcc-toolchain cannot be expected sonner than in 5.14.2.1 (don't ask me when as our release schedule is slightly demolished - as you have probably noticed) BTW for all that might be interested - latest RC's are available at: http://strawberryperl.com/package/kmx/p5.14.2.0-RC/ -- kmx
Re: Config{libpth} substitution problem
Chris, there is always a chance :) But seriously, we are currently focusing on releasing 5.14.2.0 (MSI). Alias is the person to answer the question about the next portable release. My guess is that it is more likely to see a new 5.14.2.-portable than new 5.12.-portable (but it is just my guess). -- kmx On 31.10.2011 21:12, chm wrote: Thanks, kmx. With the patch applied, I was able to build and install Prima and Prima::OpenGL on strawberry perl portable 5.12.3.0. Any chance of releasing an updated spp with the patch for 5.12? --Chris On 10/31/2011 8:13 AM, kmx wrote: It is a bug in strawberry portable perl - probably the same as https://rt.cpan.org/Ticket/Display.html?id=68937 According to my testing the enclosed portable_libpth_ugly_hack.diff should fix it -- kmx On 31.10.2011 12:30, chm wrote: For reference, this problem was for the portable edition at http://strawberryperl.com/download/5.12.3.0/strawberry-perl-5.12.3.0-portable.zip with the following perl -V output: Summary of my perl5 (revision 5 version 12 subversion 3) configuration: Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='Win32 strawberryperl 5.12.3.0 #1 Sun May 15 09:44:53 2011 i386' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READFIX', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.4.3', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++.exe', ldflags ='-s -L"C:\chm\strawberry\perl_512_3_0\perl\lib\CORE" -L"C:\chm\strawberry\perl_512_3_0\c\lib"' libpth=C:\chm\strawberry\perl_512_3_0\c\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl512.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"C:\chm\strawberry\perl_512_3_0\perl\lib\CORE" -L"C:\chm\strawberry\perl_512_3_0\c\lib"' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Built under MSWin32 Compiled at May 15 2011 14:40:22 @INC: C:/chm/strawberry/perl_512_3_0/perl/site/lib C:/chm/strawberry/perl_512_3_0/perl/vendor/lib C:/chm/strawberry/perl_512_3_0/perl/lib . Cheers, Chris On 10/31/2011 6:19 AM, Dmitry Karasik wrote: Hello, I have I problem with building Prima on strawberry 5.12.3, which appears when I use Strawberry installed in something other than c:/strawberry directory. The problem didn't re-appear cleanly when I tried to take a clean vmware box, and install it there, so I'm not 100% sure how to reproduce it. However a Prima user send that bug to me, so there's something wrong not only on my machine. The problem is as such: Prima needs libgdi32.a, which is not found because $Config{libpth} doesn't contain the path to it (it's in c:/somewhere_else/c/i686-w64-mingw32/lib ). However in Config.pm there is this line: libpth => 'C:\\strawberry\\c\\lib C:\\strawberry\\c\\i686-w64-mingw32\\lib', which seems valid, but if I call either 'perl -V:libpth' or 'perl -MConfig -le "print $Config{libpth}" I get printed c:\somewhere_else\c\lib only. Some substitution gone wrong. To test this further I've temporarily removed Config.pm to see if some other Config.pm gets picked, - no, it wasn't. Next, I've hacked a copy of Config.pm into Config2.pm (and renamed it inside), and unsurprisingly, calling 'perl -MConfig2 -le "print $Config{libpth}' yielded just that unsubstituted line: C:\strawberry\c\lib C:\strawberry\c\i686-w64-mingw32\lib I tried to find where the substitution magic is executed to see if the problem is indeed there, but couldn't find where it gets done. So I'll need your help here. If anyone can confirm that (and when) $Config{libpth} gets hacked, or point me to the code where the magic is done, that'd be really appreciated.
Re: Config{libpth} substitution problem
It is a bug in strawberry portable perl - probably the same as https://rt.cpan.org/Ticket/Display.html?id=68937 According to my testing the enclosed portable_libpth_ugly_hack.diff should fix it -- kmx On 31.10.2011 12:30, chm wrote: For reference, this problem was for the portable edition at http://strawberryperl.com/download/5.12.3.0/strawberry-perl-5.12.3.0-portable.zip with the following perl -V output: Summary of my perl5 (revision 5 version 12 subversion 3) configuration: Platform: osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread uname='Win32 strawberryperl 5.12.3.0 #1 Sun May 15 09:44:53 2011 i386' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -mms-bitfields -DPERL_MSVCRT_READFIX', optimize='-s -O2', cppflags='-DWIN32' ccversion='', gccversion='4.4.3', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='g++.exe', ldflags ='-s -L"C:\chm\strawberry\perl_512_3_0\perl\lib\CORE" -L"C:\chm\strawberry\perl_512_3_0\c\lib"' libpth=C:\chm\strawberry\perl_512_3_0\c\lib libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 libc=, so=dll, useshrplib=true, libperl=libperl512.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-mdll -s -L"C:\chm\strawberry\perl_512_3_0\perl\lib\CORE" -L"C:\chm\strawberry\perl_512_3_0\c\lib"' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PL_OP_SLAB_ALLOC USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Built under MSWin32 Compiled at May 15 2011 14:40:22 @INC: C:/chm/strawberry/perl_512_3_0/perl/site/lib C:/chm/strawberry/perl_512_3_0/perl/vendor/lib C:/chm/strawberry/perl_512_3_0/perl/lib . Cheers, Chris On 10/31/2011 6:19 AM, Dmitry Karasik wrote: Hello, I have I problem with building Prima on strawberry 5.12.3, which appears when I use Strawberry installed in something other than c:/strawberry directory. The problem didn't re-appear cleanly when I tried to take a clean vmware box, and install it there, so I'm not 100% sure how to reproduce it. However a Prima user send that bug to me, so there's something wrong not only on my machine. The problem is as such: Prima needs libgdi32.a, which is not found because $Config{libpth} doesn't contain the path to it (it's in c:/somewhere_else/c/i686-w64-mingw32/lib ). However in Config.pm there is this line: libpth => 'C:\\strawberry\\c\\lib C:\\strawberry\\c\\i686-w64-mingw32\\lib', which seems valid, but if I call either 'perl -V:libpth' or 'perl -MConfig -le "print $Config{libpth}" I get printed c:\somewhere_else\c\lib only. Some substitution gone wrong. To test this further I've temporarily removed Config.pm to see if some other Config.pm gets picked, - no, it wasn't. Next, I've hacked a copy of Config.pm into Config2.pm (and renamed it inside), and unsurprisingly, calling 'perl -MConfig2 -le "print $Config{libpth}' yielded just that unsubstituted line: C:\strawberry\c\lib C:\strawberry\c\i686-w64-mingw32\lib I tried to find where the substitution magic is executed to see if the problem is indeed there, but couldn't find where it gets done. So I'll need your help here. If anyone can confirm that (and when) $Config{libpth} gets hacked, or point me to the code where the magic is done, that'd be really appreciated. diff -ru portable.orig\perl\ve
Re: gcc for building Perl on WinXP
In preparing the next Strawberry release you've no doubt noticed that mingw-w64 32bit version cannot build a working Perl after gcc version 4.4.3 on Windows XP. Yes, in fact it was during the last week when we have found out (with help of BinGOs and Ranguard via IRC) that gcc-4.4.7 and 4.6.1 (not only with mingw-w64 runtime but also with mingw.org's runtime) produce perl binaries that crash on Windows XP. For strawberry perl 5.14.2.0 we have decided to use: - on 32 bit version gcc-4.4.3 (with slightly old mingw-w64 runtime) http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-20100123-kmx-v3.zip - on 64 bit version gcc-4.4.7(prereleae) (with mingw-w64 runtime 1.0.1) http://strawberryperl.com/package/kmx/64_gcctoolchain/mingw64-w64-gcc4.4.7(pre)_20111014.zip Commit 180422 to the 4.6 branch of gcc fixes the problem - I've cross compiled my own 32bit 4.6.2 release (the tagged 4.6.2 release includes this fix) which compiles a working Perl 5.14.2 on Windows XP. Many thanks , this is a valuable piece of information for me as I was in doubts where to start reporting/discussing the issue, now it is clear. For my own use, I need to move to 4.6.2 as 4.4.7 cannot compile wxWidgets 2.9.x branch. As a side benefit I also get an up to date v2 mingw-w64 crt. I'll be publishing source, patches and build instructions at http://perlmingw.sourceforge.net/ (plus, of course, the compiled releases). The patches are just the minimum necessary from sezero build and TDM GCC builds to get a working dist. Just a thought, but it might be nice if we had a sort of 'standard' gcc for Perl on Windows. Why not. As for my opinion concerning gcc toolchain included in strawberry perl: - we would strongly prefer to use mingw-w64 (not mingw.org) runtime for both 32/64bit - we have no special preference as for the gcc version (but versions like gcc-X.Y.0 are perhaps too "in development" for us) - we need gcc toolchain supporting/include and/lib directories in search paths (without explicit -I or -L options) - we would appreciate gcc toolchain with frotran (maybe a kind of addon or extra package) as it comes handy to PDL guys using strawberry Anyhow, I think you could just backport the fix to the current 4.4.7 branch. But, for what it is worth, Strawberry users will be unable to compile wxWidgets 2.9.x branches (without some patching at least) OK, I take it as your "gcc upgrade" request - we will probably aim at gcc-4.6.2 + mingw-w64 runtime (v2 or latest v2RC) However, currently the release candidates for strawberry 5.14.2.0 are IMHO too good to let them fall on the floor. I think that the updated gcc-toolchain cannot be expected sonner than in 5.14.2.1 (don't ask me when as our release schedule is slightly demolished - as you have probably noticed) BTW for all that might be interested - latest RC's are available at: http://strawberryperl.com/package/kmx/p5.14.2.0-RC/ -- kmx
Re: Can't compile anything - *.h missing ??
> Ideas? Help with how to diagnose? Any thoughts MUCH appreciated! Could you please send outputs of the following commands: 1/ perl -V:myuname 2/ gcc -v ... 3/ echo PATH=%PATH% 4/ echo C_INCLUDE_PATH=%C_INCLUDE_PATH% Could you check which of the following files exist on your system? - c:\strawberry\c\i686-w64-mingw32\include\stdlib.h - c:\strawberry\c\x86_64-w64-mingw32\include\stdlib.h - c:\strawberry\c\include\stdlib.h -- kmx
Re: Which way is the true way, and what not? "-lssleay32 -llibeay32" Way? Or "-lssl -lcrypto" Way? Fw: HowTo: Strawberry Perl v5.12.3 x64 upgrade to OpenSSL v1.0.0d from "OpenSSL 1.0.0-beta4"
Dne 2.6.2011 18:05, Victor Miasnikov napsal(a): > Hi! >>> Question N2: where to download / get / take openssl.cnf for OpenSSL from >>> *_20110507.zip? >> Take apps/openssl.cnf from the original openssl-1.0.0d.tar.gz tarball. > Thanks! > > But you must agree to the OpenSSL in Strawberry Perl incomplete OpenSSL included in strawberry perl is complete enough as regards openssl related perl modules. The ambition was not to be 100% complete openssl distribution. You are AFAIK the first one complaining about openssl incompleteness. Compare with postgresql - we are not packaging the complete postgresql but just a subset necessary to build postgres related perl module(s). > And where to download / get / take .dll from \openssl\lib\engines > > 4758ccaeay32.dll > aepeay32.dll > atallaeay32.dll > capieay32.dll > chileay32.dll > cswifteay32.dll > gmpeay32.dll > gosteay32.dll > nuroneay32.dll > padlockeay32.dll > surewareeay32.dll > ubseceay32.dll > > ? Here you are: http://strawberryperl.com/package/kmx/tmp-for-victor/ -- kmx
Re: Which way is the true way, and what not? "-lssleay32 -llibeay32" Way? Or "-lssl -lcrypto" Way? Fw: HowTo: Strawberry Perl v5.12.3 x64 upgrade to OpenSSL v1.0.0d from "OpenSSL 1.0.0-beta4"
> > We will go step by step: > > The practical question: .dll / .lib files from > 64bit_openssl-1.0.0d-bin_20110507.zip build via Configure + make? Or with > mingw32.bat? Or copy from "openssl Win32 binaries distribution"? There are no *.lib just *.a They are built via Configure + make and renamed to follow the naming convention as if they were build by mingw.bat (it is because in the past we were using mingw32.bat for building openssl and we want to be consistent across strawberry releases). > > Question N2: where to download / get / take openssl.cnf for OpenSSL from > * _20110507.zip? Take apps/openssl.cnf from the original openssl-1.0.0d.tar.gz tarball. -- kmx
Re: Which way is the true way, and what not? "-lssleay32 -llibeay32" Way? Or "-lssl -lcrypto" Way? Fw: HowTo: Strawberry Perl v5.12.3 x64 upgrade to OpenSSL v1.0.0d from "OpenSSL 1.0.0-beta4"
Hi Victor, > a) "-lssleay32 -llibeay32" Way: > > At this moment in strawberry-perl-5.12.3.0-64bit / 5.12.2.0 and in > 64bit_openssl-1.0.0d-bin_20110507.zip : > == > libeay32__.dll > ssleay32__.dll > libeay32.a > libssl32.a > libssleay32.a > == I can give an explanation as I have prepared this part of strawberry perl. a/ libeay32.a (+libeay32__.dll) is analogy for UNIXish -lcrypto b/ libssl32.a == libssleay32.a (+ssleay32__.dll) is analogy for UNIXish -lssl The trouble is that openssl has 2 different way for building MSWindows/gcc libraries - one via Configure+make; the second via mingw32.bat. Unfortunately each way creates *.a files with different names */ Configure+make creates - libcrypto.dll.a - libcrypto.a - libssl.dll.a - libssl.a */ mingw32.bat creates - libeay32.a (= libcrypto.dll.a) - libcrypto.a - libssl32.a (= libssl.dll.a) - libssl.a On top of that you have also MS compiler (cl/msvc) in MS Windows world which uses also different library names: libeay32*.lib ssleay32*.lib (from here probably comes "-lssleay32 -llibeay32" which should be fine with MS compiler) Things get a little bit more complicated by the fact that the more-or-less official openssl Win32 binaries distribution (see http://www.openssl.org/related/binaries.html) contains also mingw/gcc *.a libraries - however named: libeay32.a + ssleay32.a (which does not correspond to the results produced by the mingw.bat from official openssl tarball). Please note that ssleay32.a is not libssleay32.a thus linker will not find it when given -lssleay32 - this is IMHO the main source of confusion about the right lib names. What we have done in strawberry was to use naming convention libeay32.a/libssl32.a + a little trick to copy libssl32.a to libssleay32.a - at that time it seemed to be a way how to satisfy most of the modules on cpan using different -lssleay32/-lssl32/-leay32 linker options I do not feel to have an authority to say what is the best/right/correct way but I would keep the naming convention of the original openssl distribution and use: -lssl32 -leay32 for MSWindows+gcc compiler (which works with openssl included in strawberry perl however not with *.a mingw libraries that are part of the openssl Win32 binaries distribution). -- kmx
Re: dmake.EXE: Error: -- Input line too long, increase MAXLINELENGTH
Hi Gabor, > ... > > The solution, > > c:> cpan > cpan> look DateTime::TimeZone >> perl Makefile.PL >> dmake MAXLINELENGTH=30 make >> dmake MAXLINELENGTH=30 make test >> dmake MAXLINELENGTH=30 make install > > I don't know if this can be changed in the next releases of Strawberry Perl > but this might help some others. It is already there (MAXLINELENGTH := 80) - I am just not sure since what release. Anyway, thanks for reporting. -- kmx
Re: Basic FAQ: how to setup local 'environment' to build CPAN modules under strawberry
Hi Linda, > I made a mistake, I had installed the 64bit version, had path probs > sometime back so uninstalled it. When I re-installed, mistakenly > installed 32-bit version, and my paths were still not right (I need to make > sure the strawberry perl paths are before the cygwin paths; didn't see > the /strawberry/C/bin, added to the path. > > Any reason why there are two separate trees @ installation? Couldn't they > be combined? c:/strawberry/c and c:/strawberry/perl contain completely different things (1st - gcc toolchain + bunch of external libs; 2nd - the perl itself + all installed modules) which is enough to keep them separately. In theory they can be combined but you have to manually hack many $Config{???} variables pointing to these dirs. > Trying to reinstall the 64-bit version now, but both of the > MSI's (strawberry-perl-5.12.1.0-64bit.msi) > <https://www.ohloh.net/p/strawberry-perl/download?filename=strawberry-perl-5.12.1.0-64bit.msi> > listed on the versions page seem to be not-working. > 1st) points to ohloh (dead), You are right. > 2nd points to: > http://strawberryperl.com/download/5.12.1.0/strawberry-perl-5.12.1.0-64bit.msi > > but is never coming back with a save-dialog. This one works for me, maybe some temporary issue. > I can download the .zip -- but what does the MSI do to 'install' it? > Seem I remembered some relocation operations whizzing by on my last install. To install a ZIP distribution 1. unzip strawberry-perl-5.12.1.0-64bit into a dir without spaces in its name - e.g. c:\perl64bit\ 2. run c:\perl64bit\relocation.pl.bat 3. run c:\perl64bit\update_env.pl.bat (it might be necessary to logout/login to update your environment variables set in steb 3.) > I have a bunch of existing scripts that are shared with my linux systems. > They all start with: > #!/usr/bin/perl -w > > If I create a link to strawberry perl, should everything work correctly? Shebang line is (mostly) ignored on MS Windows. AFAIK the only case when it does matter is when you are running your perl script via FastCGI (Apache + mod_fastcgi). To run a perl script you can lauch: c:\> perl scriptname.pl Strawberry perl unfortunately does not associate .pl extension but you can do it by hand via commands:| |c:\> assoc .pl=PerlScript|| c:\> ftype PerlScript=c:\perl64bit\perl\bin\perl.exe %1 %* After that you can simply run your script like this: c:\> scriptname.pl -- kmx