HTTP::Server::Simple now works on Win32
Hi, it might sound unbelievably but currently released HTTP::Server::Simple 0.39 installs on Win32 without failing tests (at least on my strawberry). -- kmx
Re: Well, perl 5.10.1 is now released...
Hi Curtis, > B) wait until I can integrate the new toolchain libraries that kmx has > been working on for us - which will probably be about a week. The new external bin libs are ready to be released at least with next strawberry build. Here is the list of proposed changes: 1) Reorganised zlib - http://rt.cpan.org/Ticket/Attachment/650389/333164/libzlib-1.2.3-bin_20090819.zip - DLLs: zlib1.dll - more info: http://rt.cpan.org/Ticket/Display.html?id=48671 2) Reorganised libiconv, libintl - http://strawberryperl.com/package/libiconv-08192009.zip - DLLs: libcharset1.dll, libiconv2.dll, libintl3.dll - the credits for this pack are yours - please remove *.la, *.def, *.alias from lib subdir - more info: http://rt.cpan.org/Ticket/Display.html?id=48765 3) Rebuilt libxml2 - http://rt.cpan.org/Ticket/Attachment/650397/333188/libxml2-2.7.3-bin_20090819.zip - DLLs: libxml2_.dll - more info (xml2/xslt): http://rt.cpan.org/Ticket/Display.html?id=48576 4) NEW: libxslt - http://rt.cpan.org/Ticket/Attachment/650394/333179/libxslt-1.1.24-bin_20090819.zip - DLLs: libexslt_.dll, libxslt_.dll - why? - XML::LibXSLT - more info (xml2/xslt): http://rt.cpan.org/Ticket/Display.html?id=48576 5) NEW: openssl - http://rt.cpan.org/Ticket/Attachment/651158/333680/libopenssl-0.9.8k-bin_20090820.zip - DLLs: libeay32_.dll libssl32_.dll - why? - Crypt::SSLeay, Net::SSLeay - more info: http://rt.cpan.org/Ticket/Display.html?id=48447 6) NEW: postrgres/libpq - http://rt.cpan.org/Ticket/Attachment/651196/333705/libpostgresql-8.4.0-bin_20090821.zip - DLLs: libpq_.dll - why? - DBD::Pg - more info: http://rt.cpan.org/Ticket/Display.html?id=48447 - NOTE: missing kerberos/gssapi support 7) NEW: graphics libs (libjpeg, libgif, linpng, libtiff, libfreetype) - http://rt.cpan.org/Ticket/Attachment/651332/333799/libtiff-3.8.2-1-bin_20090821.zip - http://rt.cpan.org/Ticket/Attachment/651328/333787/libjpeg-6b-4-bin_20090821.zip - http://rt.cpan.org/Ticket/Attachment/651330/333793/libpng-1.2.37-bin_20090821.zip - http://rt.cpan.org/Ticket/Attachment/651319/333776/libgif-4.1.4-1-bin_20090821.zip - http://rt.cpan.org/Ticket/Attachment/652060/334193/libfreetype-2.3.5-1-bin_20090823.zip - DLLs: freetype6.dll, giflib4.dll, jpeg62.dll, libpng12.dll, libpng3.dll, libtiff3.dll - why? - Imager (required by MojoMojo) - more info: http://rt.cpan.org/Ticket/Display.html?id=48759 8) NEW: Berkley DB - http://rt.cpan.org/Ticket/Attachment/648921/332210/libdb-4.7.25-bin_20090817.zip - DLLs: none (I have decided to include just static *.a library) - why? - DB_File (required by Bio::Perl) - more info: http://rt.cpan.org/Ticket/Display.html?id=42167 It would be nice to include the libs above into some of the next betas as I would appreciate some feedback from more testers. -- kmx
Re: Howto Setup for Strawberry Perl
Hi, > ... > #!C:\strawberry\perl\bin\perl.exe > > but my perl executable is in > > #!C:\perl\perl\bin\perl.exe > > Do I have to change _all_ occurences of the > shebang line? > > Is there something like a common configuration file for perl? > try if you can live with this: #!perl > remark: The main purpose of this perl installation will be > to use it with Apache 2.2, but not only with apache. > Should be a full replacement for ActiveState Perl. > As for the Apache on Win32 strawberry perl works fine via FastCGI, mod_perl is known to be a problem as the official Apache binaries are compiled by MS compiler whereas strawberry uses gcc compiler - making these two to work together is technically feasible but not easy. -- kmx
Re: Problem using cpan install of any module
Dne 26.1.2010 18:19, john.king...@convergys.com napsal(a): > ... > Can someone point in the right direction to figure this out? I do have > administrator rights on this WinXP Professional. > ... > Try to disable your anti-virus SW and run "cpan install IO::All" again. I have experienced exactly the same issue on a computer with Microsoft Security Essentials. My theory is: - cpan clients unpacks a bunch of data - immediately after that cpan clients tries to move the whole upacked dir somewhere else - however AV has kind of a lock on the original directory as it did not finish the scanning of new files before "move dir" was called - from the outside it simply seems like "move failed" You can even try to run the same command multiple times and you will see that the reported error is not 100% deterministic. -- kmx
Image::Magick now works with Strawberry Perl
Hi, for those who might be interested - Strawberry Perl is supported by Image::Magick since quite recently released v6.5.9: 1) You need to install ImageMagick MS Windows binaries before installing the perl module (see Image::Magic's README.txt for what binaries to use) 2) Then you can just: cpan -i Image::Magic (compilation + all tests pass smoothly) -- kmx
Re: DBD::DB2 on strawberry perl
Dne 12.3.2010 15:29, Kartik Thakore napsal(a): > Hi Folks, > > I cannot get DBD::DB2 to compile on strawberry perl. I have read the > CAVEATS file and set the required parameters to point to the DB2 client > libraries. However it seems the client libraries are compile for MSVC and > not gcc because I get the following undefined errors: > > dbdimp.o:dbdimp.c:(.text+0x3dd): undefined reference to `sqledosd_...@16' > > > > I did ask for help on the DBI-help mailing list a while back with no luck. > > What can I do to get this working? > > regards, > kthakore > Hi Kartik, try this patched version: http://strawberryperl.com/package/kmx/perl-modules-patched/DBD-DB2-1.78_patched.tar.gz simply: c:\> set DB2_HOME=where-you-have-DB2-client-installed... c:\> pip http://strawberryperl.com/package/kmx/perl-modules-patched/DBD-DB2-1.78_patched.tar.gz If it does work for you feel free to submit this simple patch to DBD::DB2 authors: http://strawberryperl.com/package/kmx/perl-modules-patched/DBD-DB2-1.78_gcc.patch -- kmx
Re: DBD::DB2 on strawberry perl
Dne 15.3.2010 16:18, Curtis Jewell napsal(a):
> Good catch, but I would have had the patch complain and "exit(0) if not
> defined $ENV{DB2_HOME};".
>
> --Curtis
>
Good point, improved version:
http://strawberryperl.com/package/kmx/perl-modules-patched/DBD-DB2-1.78_patched2.tar.gz
The improved patch itself:
http://strawberryperl.com/package/kmx/perl-modules-patched/DBD-DB2-1.78_gcc_v2.patch
Kurtik, could you please test it against a real DB2?
--
kmx
Re: Spamassassin and openssl
Dne 9.4.2010 19:24, Michael Papet napsal(a): > Hi, > > I've been a longtime user and now have a new project requiring spamassassin. > (SA) One of the many dependencies of SA is openssl. Openssl doesn't build > with the MinGW supplied by strawberry perl. It configures properly, but > doesn't build. > > Getting openssl to build with MinGW is way above my skill set. Does anyone > have some experience getting it to build? Perl needs the header files too, > so some of the binaries that are out there won't do the job. > > Otherwise, I'd like to make a strawberry perl openssl a feature request. > > Keep up the great work. > OpenSSL is already included in Strawberry Perl - IIRC since October 2009 release. -- kmx
Re: Spamassassin and openssl
Hi Michael, you need to patch Makefile.PL (for both Crypt-OpenSSL-Random and Crypt-OpenSSL-RSA) in this way: - 'LIBS'=> ['-lssl -lcrypto'], + 'LIBS'=> ($^O eq 'MSWin32') ? ['-lssl32 -leay32'] : ['-lssl -lcrypto'], With this patch both modules work nice on my MS Windows box with Januar 2010 Strawberry Perl. I have created the following bug reports: 1/ http://rt.cpan.org/Public/Bug/Display.html?id=56454 2/ http://rt.cpan.org/Public/Bug/Display.html?id=56455 feel free to post some supportive comments to those RTs -- kmx
Re: Strawberry Perl, patch.exe and UAC
Dne 26.4.2010 19:32, Gabor Szabo napsal(a): > http://somethingdoug.com/thoughts/2010/04/26/strawberry-perl-patch-exe-and-uac/ > > Gabor > Gabor, this issue was reported and fixed as RT http://rt.cpan.org/Public/Bug/Display.html?id=55169 As stated it the linked article, Strawberry Perl April 2010 has fix for this. FYI - UAC aware 32bit + 64bit patch.exe are available at: http://strawberryperl.com/package/kmx/32_tools/32bit_patch-2.5.9-7-bin_20100110_UAC.zip http://strawberryperl.com/package/kmx/64_tools/64bit_patch-2.5.9-7-bin_20100110_UAC.zip Anyway thanks for pointing to an interesting Win32::Exe approach. -- kmx
Re: Which pptimized XML parser can be used with Perl?
Dne 25.5.2010 8:11, Sharma, Sushil napsal(a): > > Hi All, > > I am using XML::Simple in one of my project assignment with Perl 5.8.1r5. > I am observing that this XML utility is taking a lot of memory when we have a > large input file for parsing. > Because of this reason when multiple clients are invoking this Perl script, > system memory is becoming an issue. > > I wanted to know if there is any other flavor of XML parser available with > Perl which uses less memory. > > Thanks & Regards, > Sushil Sharma > As for the "more robust" XML parser check the following: 1/ XML::LibXML::Parser (based on libxml2 library - http://www.xmlsoft.org/) 2/ XML::Parser (based on expat library http://expat.sourceforge.net/) Depending on what exactly you want to achieve you might find some even more suitable modules on CPAN (e.g XML::Rules build on top of XML::Parser + many others). -- kmx
Strawberry perl + mod_perl (call for testers)
To anyone who might be interested in mod_perl working with Strawberry Perl:
1/ On strawberry perl 5.12.x (32bit) run from command prompt:
perl -MPAR::Dist -e
install_par('http://strawberryperl.com/package/kmx/mod_perl/5.12_x86/mod_perl-2.0.4-MSWin32-x86-multi-thread-5.12.par')
perl -MPAR::Dist -e
install_par('http://strawberryperl.com/package/kmx/mod_perl/5.12_x86/libapreq2-2.12-MSWin32-x86-multi-thread-5.12.par')
All other necessary files (mod_perl.so, mod_apreq2.so, libapreq2.dll) are
available at http://strawberryperl.com/package/kmx/mod_perl/5.12_x86/
For sample setup see
http://strawberryperl.com/package/kmx/mod_perl/README-512.TXT
2/ On strawberry perl 5.10.x (32bit) - run from command prompt:
perl -MPAR::Dist -e
install_par('http://strawberryperl.com/package/kmx/mod_perl/5.10_x86/mod_perl-2.0.4-MSWin32-x86-multi-thread-5.10.par')
perl -MPAR::Dist -e
install_par('http://strawberryperl.com/package/kmx/mod_perl/5.10_x86/libapreq2-2.12-MSWin32-x86-multi-thread-5.10.par')
All other necessary files (mod_perl.so, mod_apreq2.so, libapreq2.dll) are
available at http://strawberryperl.com/package/kmx/mod_perl/5.10_x86/
Both should work with Apache-2.2 Win32 binaries either from
http://www.apache.org/dist/httpd/binaries/win32/ of from
http://www.apachelounge.com/download/
TESTERS WELCOME - if you are gonna test the above mentioned binaries please
send a feedback either to this list or even better post it to the RT -
http://rt.cpan.org/Public/Bug/Display.html?id=58512
--
kmx
Re: question about Perl with Mingw
Dne 24.6.2010 23:44, LM napsal(a): > Can I delete the extra mingw compiler downloaded with Strawberry Perl > and simply adjust my path via the command line to point to both the > Strawberry Perl bin directory and the mingw bin directory? > Technically it is possible (you just have to avoid mixing 32/64bit perl and gcc compiler). > Is that all I'd need to do or are there other settings required. > Apart from mingw compiler (gcc toolchain + binutils + C-runtime) you need: 1/ dmake.exe = absolute must 2/ patch.exe, pexports.exe, gmake.exe or mingw32-make.exe (for building some modules from CPAN) 3/ Keep in mind that c:\strawberry\c directory does not contain only gcc compiler but also a bunch of external libraries (libexpat, libgdbm, berkeleydb, libxml2, libxslt, openssl, mysql, postgres, gmp, mpc, mpfr and many others). These libs are needed for building certain perl modules. You can download them separately from http://strawberryperl.com/package/kmx/32_libs Please note that since 5.12 release strawberry uses gcc 4.4.3 toolchain from http://mingw-w64.sf.net project not from http://mingw.org - the main reason was that mingw.org delivers just 32bit compiler whereas mingw-w64.sf.net delivers both 32 and 64bit native gcc compiler. I personally do not see any reason why strawberry should switch back. > MinGW's msys supplies a version of Perl in the msysDTK file and Strawberry > Perl supplies a copy of MinGW. Both of these appear to be older versions. > (I don't think MinGW specifically supplies Strawberry Perl or Vanilla Perl, > but I don't think their Perl distribution is the latest either.) What I > really want is to run the best and latest distributions of both MinGW and > Perl. Is there any way these two projects can get together and work out > supplying later versions of each other's tools? The biggest trouble of mixing MSYS environment with strawberry perl is the fact that MSYS environment is using UNIX-like paths like /usr/local/whatever which are not understood by strawberry perl (from obvious reasons). Of course you can even in MSYS environment use paths like c:/dirname/subdir which strawberry can handle but strawberry simply is not 100% replacement of perl delivered with MSYS. -- kmx
Re: Tk problem building / installing using Perl 5.12.0.1 on x64
Dne 27.7.2010 17:39, Paul napsal(a): > ... > > Starting at 43: > 43: #ifdef _DWIN64 > 44: typedef __int64 XID; > 45: #else > 46: typedef unsigned long XID; > 47: #endif > > I was able to correct this by changing this to > 43: #ifdef _DWIN64 > 44: #include > 45: typedef __int64 XID; > 46: #else > 47: typedef unsigned long XID; > 48: #endif > The trouble is that IIRC __int64 is not supported by gcc as a native/built-in type therefore you have to include "some" header defining it. Your patch is technically correct and should work with both gcc and msvc compilers. Another way (IMHO more compiler-portable) to handle this is: 43: #ifdef _DWIN64 44: typedef unsigned long long XID; 45: #else 46: typedef unsigned long XID; 47: #endif Anyway, as mentioned by Curtis in his post, this should be patched in Tk module. -- kmx
Re: Basic FAQ: how to setup local 'environment' to build CPAN modules under strawberry
Hi Linda, > I'm new the the strawberry distro, and need to install a bunch of > CPAN modules. It doesn't seem that it comes with the necessary > build utils to do so. > > Is there a single-install that would install all the needed utils > to build the CPAN modules? All the required tools (compiler, linker & co.) comes with strawberry perl, they are installed always (you cannot choose not to install them) - so providing you have installed 64bit strawberry perl (5.12.x) you have installed all you need for building CPAN modules. Depending on what installation procedure you have chosen - ZIP, MSI - there might be a trouble with properly set PATH env variable. Open a command prompt window (cmd.exe - neither powershell nor anything else) type "set" and check whether you have the following dirs in your PATH (in given order): c:\strawberry\perl\site\bin c:\strawberry\perl\bin c:\strawberry\c\bin (replace "c:\strawberry\" with a dir into which you have installed strawberry perl) >From the same command promp you can check: 1. command "gcc --version" should return "gcc (GCC) 4.4.3" 2. command "perl -V:myuname" should return "Win32 strawberryperl 5.12 x64" 3. command "dmake -V" should say "dmake - Version 4.12 (Windows / MinGW)" To install any module from CPAN run from the same command prompt: c:\> cpan -i Module::Name (CPAN client in strawberry perl comes pre-configured, no need to setup anything) If you want do download and install a module manually it works similarly as in cygwin just use "dmake" instead of "make" - so from command prompt: c:\module-src> perl Makefile.PL c:\module-src> dmake c:\module-src> dmake test c:\module-src> dmake install > All that said -- my real preference would be that all of strawberry and > the modules work on Win64, since I don't want to be limited to the 32-bit > sections of the registry and 32-bit redirections in the file system. Just keep in mind that some modules that work fine on 32bit MS Windows do not work well on 64bit MS Windows (check bug reports for particular module). > My biggest itch is in path separators. While many Win utils handle "/" > as well as "\", some don't. But even some (many?) system calls or api > calls handle either (registry accesses); apparently MS-internal > programmers found using '\\' all over the place as noxious as anyone > else. Given most of their code was in 'C'-syntax compat languages. The advice is simple - consistently use File::Spec functions/methods and your scripts will work (more or less) across platforms. > A 64-bit BASH replacement would be REALLY appreciated, since there's > already a 64-bit 'Console2' version that could be using it -- with that, > anything I call can run in 64 (or 32-bit) mode, though by default, any > progs I call from the 32-bit bash get invoked in a 32-bit form (if they > work at all). Many times, I am tracking down problems in scripts > and the problem is that they stem from the 32-bit shell having > invoked a 32-bit version of some program or worse -- some registry or > file subtree that is redirected for 32-bit progs -- making me waste time > trying to figure out why it isn't giving me the 'right' answer as I > look at the tree with other 64-bit tool*face-slap*. If I can recommend - start using strawberry perl together with standard command prompt (cmd.exe), this way it is known to work - this way it is well tested. -- 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
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: 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: 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"
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: 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: 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: 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: 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: 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: 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
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
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
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
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: 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: 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: 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: 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: 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: 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
> 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: 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
> 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
strawberry perl 5.16 BETA available for testing
Check http://strawberryperl.com/beta/ Any feedback welcome. -- 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
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
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
> 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
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: 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
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
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: 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 & 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 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.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
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
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
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: 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
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
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
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
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
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 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
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: 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: 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: 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
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: 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.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: 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
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 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
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
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: 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: 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
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: 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
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
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
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: 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: 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 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: 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
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: 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 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: 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.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
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
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
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: 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: 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: 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.
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
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
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
