Strawberry Perl 5.24.2.1 released
Strawberry Perl 5.24.2.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.24.2.1-64bit.html http://strawberryperl.com/release-notes/5.24.2.1-32bit.html I would like to thank our sponsor Enlightened Perl Organisation [http://www.enlightenedperl.org] for resources provided to our project. -- kmx
Strawberry Perl 5.22.1.3 + 5.20.3.3 released
Strawberry Perl 5.22.1.3 and 5.20.3.3 are available at http://strawberryperl.com Both contain security fixes for CVE-2015-8607 + CVE-2015-8608 + CVE-2016-2381 + the latest openssl. More details in Release Notes: http://strawberryperl.com/release-notes/5.22.1.3-64bit.html http://strawberryperl.com/release-notes/5.22.1.3-32bit.html http://strawberryperl.com/release-notes/5.20.3.3-64bit.html http://strawberryperl.com/release-notes/5.20.3.3-32bit.html A note for PDL and long-double fans: from http://strawberryperl.com/releases.html you can download experimental strawberry-perl-ld-5.22.1.3-64bit-PDL.zip <http://strawberryperl.com/download/5.22.1.3/strawberry-perl-ld-5.22.1.3-64bit-PDL.zip> I would like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Strawberry Perl 5.22.1.1 released
Strawberry Perl 5.22.1.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.22.1.1-32bit.html http://strawberryperl.com/release-notes/5.22.1.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: Strawberry Perl 5.22.1.1 released
On 18.12.2015 18:37, John Maag via win32-vanilla wrote: How does one request a module to be added to Stawberry perl? I would like to request Filesys::DfPortable be added Simply open a "bug" via https://rt.cpan.org/Public/Dist/Display.html?Name=Perl-Dist-Strawberry -- kmx
Strawberry Perl 5.20.3.1 released
Strawberry Perl 5.20.3.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.20.3.1-32bit.html http://strawberryperl.com/release-notes/5.20.3.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation <http://www.enlightenedperl.org> for resources provided to our project. -- kmx
Re: source code for the 5.16.1.1 release
Yes, that's it. -- kmx On 15.8.2015 0:19, Joe Malcolm wrote: Right, but can I expect that: svn co http://svn.code.sf.net/p/mingw-w64/code/trunk@4936 Would get me the right version? Joe On Aug 14, 2015, at 15:59 , kmx k...@atlas.cz mailto:k...@atlas.cz wrote: Hi, 4936 is SVN revision number. After mingw-w64 project had migrated to git I am not quite sure what is the corresponding git commit. -- kmx On 14.8.2015 20:01, Joe Malcolm wrote: First, thanks a lot for your work on Strawberry Perl - it’s made my life quite a bit easier. I am wondering how to find the source code for the mingw-w64-crt” component of this release. On http://strawberryperl.com/release-notes/5.16.1.1-32bit.html it’s listed as: mingw-w64-crt_2.x_r4936 http://mingw-w64.sourceforge.net/ But r4936 does not seem to be available in the git repository. E.g.: git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 mingw-w64-mingw-w64 gives me a repo which seems to go from 4934 to 4950: commit 9ea33d20a97d5f8812233c2d6682af2461707df1 Author: Ozkan Sezer seze...@gmail.com 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 cja...@gmail.com mailto:cja...@gmail.com Date: Mon Apr 2 07:45:47 2012 + Makefile.am: Added downloadmgr.idl to IDL_SRCS (missing in previous patch) git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@4934 4407c894-4637-0410-b4f5-ada5f102cad1 svn co http://svn.code.sf.net/p/mingw-w64/code/trunk@4936” gets me something, but it’s hard to tell if it’s what I want. I’d appreciate any help. Thanks, Joe
Re: source code for the 5.16.1.1 release
Hi, 4936 is SVN revision number. After mingw-w64 project had migrated to git I am not quite sure what is the corresponding git commit. -- kmx On 14.8.2015 20:01, Joe Malcolm wrote: First, thanks a lot for your work on Strawberry Perl - it’s made my life quite a bit easier. I am wondering how to find the source code for the mingw-w64-crt” component of this release. On http://strawberryperl.com/release-notes/5.16.1.1-32bit.html it’s listed as: mingw-w64-crt_2.x_r4936 http://mingw-w64.sourceforge.net/ But r4936 does not seem to be available in the git repository. E.g.: git clone git://git.code.sf.net/p/mingw-w64/mingw-w64 mingw-w64-mingw-w64 gives me a repo which seems to go from 4934 to 4950: commit 9ea33d20a97d5f8812233c2d6682af2461707df1 Author: Ozkan Sezer seze...@gmail.com 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 cja...@gmail.com mailto:cja...@gmail.com Date: Mon Apr 2 07:45:47 2012 + Makefile.am: Added downloadmgr.idl to IDL_SRCS (missing in previous patch) git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk@4934 4407c894-4637-0410-b4f5-ada5f102cad1 svn co http://svn.code.sf.net/p/mingw-w64/code/trunk@4936” gets me something, but it’s hard to tell if it’s what I want. I’d appreciate any help. Thanks, Joe
Strawberry Perl 5.20.2.1 released
Strawberry Perl 5.20.2.1 is available at http://strawberryperl.com More details in Release Notes: http://strawberryperl.com/release-notes/5.20.2.1-32bit.html http://strawberryperl.com/release-notes/5.20.2.1-32bit.html http://strawberryperl.com/release-notes/5.20.2.1-64bit.html I would also like to thank our sponsor Enlightened Perl Organisation http://www.enlightenedperl.org for resources provided to our project. -- kmx
Re: Installing Alien::ffmpeg, missing pr
Hi, I think your request should be addressed to Alien::MSYS as it IMO delivers tools required for GNU style configure scripts on Windows. Odds are pretty low that these tools will be included in standard strawberry perl. But you can create a RT here: https://rt.cpan.org/Public/Dist/Display.html?Name=Perl-Dist-Strawberry just for future reference (note that there are already some bugs with subject [Extension Request] ...). -- kmx On 22.2.2015 16:12, Timm Murray wrote: I'm trying to install Alien::ffmpeg on Strawberry Perl 5.20.1.1 x64. It ends with the output below about missing the pr command, as well as yasm/nasm. It appears that several CPAN smoke test reports show the same issue. Any chance of including these in the distribution? Thanks, Timm Murray + sh configure --prefix=C:/STRAWB~1/perl/site/lib/auto/share/dist/Alien-ffmpeg configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found configure: line 402: pr: command not found yasm/nasm not found or too old. Use --disable-yasm for a crippled build.
Re: 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 k...@atlas.cz
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 k...@atlas.cz wrote:
The reason is simple - it does not build anymore as it is not able to find
required pari source tarball at
ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/
Here is a quick-and-dirty patch to work around this (but hard-wires
you to 2.1.7):
--- a/utils/Math/PariBuild.pm
+++ b/utils/Math/PariBuild.pm
@@ -301,7 +301,7 @@ EOP
}
$base_url = ftp://$host$dir;;
-my @extra_chdir = qw(OLD);
+my @extra_chdir = qw(OLD/2.1);
print Getting GP/PARI from $base_url\n;
eval {
Cheers,
-Jan
Re: StrawberryPerl and the OpenSSL heartbleed bug
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: 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 quadmath.h
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
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
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: 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 k...@atlas.cz 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 13.3.2013 23:14, sisyph...@optusnet.com.au wrote: -Original Message- From: kmx Hi, is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry Perl 5.18.x series ? I have done some testing with PDL guys approx a year ago on 5.16.0 (I guess Rob is also subscribed to this list) and AFAIK it works. I've been testing it continually over the last year or so. Every module I build (not just PDL), I've been building on USE_64_BIT_INT - for both 5.16.0 and current blead (5.17.x). I haven't struck any problems at any time that were related to the 64int architecture. Thanks for feedback. I can think of only one con: ActivePerl binaries (ppm packages) will not be usable on the 64int architecture Strawberry Perl - unless, of course, ActiveState also start providing packages for the 64int architecture. (I've no idea what ActiveState are planning to do in this regard.) I doubt that many Strawberry users (if any) would be affected by this, and I don't regard it as a stopper. On the other hand ActiveState ppm repositories use newer ppm format than ppm utility included in strawberry perl is able to handle. So it is not even today easily possible to install ppm from ActiveState repo into strawberry perl. (Will 32int Strawberry builds still be available for anyone who wants one ?) No, my idea is just one and only one 32bit strawberry perl 5.18.x with 64int. As regards the ppm packages that I provide, they'll be available for both the 64int and 32int architectures. Pros: 1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin without any special hacking that was needed for 5.16.0 2/ PDL users are gonna like it 3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit strawberry perl 4/ Couple of others asking me privately will appreciate it (they ask: why 32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?) One other thing to consider with 5.18 Strawberry is whether it should be COW-enabled or not. Until recently, the p5p plan was to make 5.18 COW-enabled, but that has now been postponed to 5.20 (which will definitely be COW-enabled). As the plan currently stands, 5.18 will build as COW-disabled by default - but there's an option to build it COW-enabled (which p5p are encouraging module authors to use - mainly to have them avoid rude shocks when 5.20 does come along). I guess Strawberry Perl would just go with the default option - though I don't have any personal preference in either direction. As for COW I am gonna follow perl core default behaviour. -- kmx
Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
Hi, is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry Perl 5.18.x series ? I have done some testing with PDL guys approx a year ago on 5.16.0 (I guess Rob is also subscribed to this list) and AFAIK it works. Pros: 1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin without any special hacking that was needed for 5.16.0 2/ PDL users are gonna like it 3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit strawberry perl 4/ Couple of others asking me privately will appreciate it (they ask: why 32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?) -- kmx
Call for opinion: strawberry perl 5.18.x/32bit with USE_64_BIT_INT
Hi, is anybody against turning on USE_64_BIT_INT in coming 32bit Strawberry Perl 5.18.x series ? I have done some testing with PDL guys approx a year ago on 5.16.0 (I guess Rob is also subscribed to this list) and AFAIK it works. Pros: 1/ perl core 5.17.* supports building perl with USE_64_BIT_INT on MSWin without any special hacking that was needed for 5.16.0 2/ PDL users are gonna like it 3/ Cool stuff like https://metacpan.org/module/Mango will work on 32bit strawberry perl 4/ Couple of others asking me privately will appreciate it (they ask: why 32bit cygwin perl can have 64_BIT_INT and 32bit strawberry not?) -- kmx
Strawberry Perl 5.16.2.2 released
Strawberry Perl 5.16.2.2 is available at http://strawberryperl.com (all editions: MSI, ZIP, PortableZIP for both: 32/64bit MS Windows) More details in Release Notes: http://strawberryperl.com/release-notes/5.16.2.2-32bit.html http://strawberryperl.com/release-notes/5.16.2.2-64bit.html -- kmx
Re: DBD::Oracle
Hi Lyle, The main reason is probably no demand for such a thing (+ other reasons like complicated build procedure, license agreements for Oracle stuff ...) If you are willing to spend some time on testing I can include DBD::Oracle (in ActivePerl way) in the next strawberry perl release. I have prepared pre-build distributions - for Strawberry Perl 5.16.2.x (32/64bit), linked with Oracle Instant Client 11.2.0.3.0: http://strawberryperl.com/package/kmx/perl-modules-par/DBD-Oracle-1.56-MSWin32-x86-multi-thread-5.16.2.par http://strawberryperl.com/package/kmx/perl-modules-par/DBD-Oracle-1.56-MSWin32-x64-multi-thread-5.16.2.par You can install them into strawberry perl simply by running: c:\ pip par_file_url 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.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: Strawberry Perl dies on Vista after August 2012 Windows Update
On 20.8.2012 15:21, Andrew Murphy (home) wrote: Hi Have Strawberry Perl 5.16 with Windows Vista – all worked fine. 1) Applied August Microsoft Security patches from Windows Update Perl wouldn’t run. 2) Googled – no mention of it. 3) Uninstalled Stawberry Perl, and removed C:\strawberry Installed latest version 5.16.1 Rebooted, Perl still wouldn’t run. 4) Went into Windows update, and backed out the security updates Rebooted, Perl now works fine (well, except for all the CPAN modules I have to re-install) (Sorry, if were Unix, I could run truss to find out what the problem was, but on Windows, I don’t know where to start) So it looks like something in the Windows Updates is causing a problem with Perl Andrew Unfortunately I do not have any Win Vista available for testing, however on my Win7 box with latest updates both 32/64bit 5.16.1.1 work fine. Are you trying to use 32 or 64 bit strawberry perl? Are you running any antivirus sw? -- kmx
Strawberry Perl 5.16 kaspersky antivirus
Does anybody experienced any troubles when installing Strawberry Perl 5.16.0.1 or 5.16.1.1 on a Windows box with kaspersy AV? I mean a trouble like this: https://rt.cpan.org/Ticket/Display.html?id=78457 -- kmx
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 k...@atlas.cz [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 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 k...@atlas.cz To: win32-vanilla@perl.org 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: problems with strawberry perl portable and cpan
kmx, have you already been working on building a 32-bit SP with -Duse64bitint ? Not yet but we already have some hackery applied on win32/config_H.gc and win32/config.gc - I expect that couple of more hacking in these two files can make use64bitint possible. I can do more on this after I release strawberry 5.16.0 (approx the end of May). -- kmx
Re: 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:\perl32perl -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 -LD:\perl32\perl\lib\CORE -LD:\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 -LD:\perl32\perl\lib\CORE -LD:\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: 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
On 25.4.2012 16:26, René Staffen wrote: Hi, I hope this is the right mailing list. it was linked from http://strawberryperl.com/support.html but its name does not sound related for me. Please inform me, it iam wrong. Beside this doubts here is my Problem: i use a portable edition of strawberry but i got problems with cpan. cpan always gives errors if perl is not present at the folder there i first used portable perl. The errors are of kind 'file not found' because cpan looks in the old directory eg: Das System kann den angegebenen Pfad nicht finden. ADAMK/DBD-SQLite-1.35.tar.gz E:\Development\Scripte\strawberry-perl-5.12.3.0-portable__\c\bin\dmake.exe -- NOT OK the current path is c:\strawberry-perl but may change because i also use this installation from USB-Stick i allready tried to delete the cpan/build folder but with no success. i allready installed many things so i do not want to start from clean installation Any hints? Please try strawberry perl portable 5.14.2.1 from release page http://strawberryperl.com/releases.html - portable 5.12.3 is buggy. -- kmx
Re: Vanilla Perl and 5.16.0
Hi 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: 5.12.3 portable / Tk installation
On 23.11.2011 12:06, Ch Lamprecht wrote:
Hello,
there is a problem with Tk-804.030 build failing using strawberry
5.12.3 portable.
The following test-report gives details (Win7). I see the same issue
trying to build Tk on WinXP 32 / strawberry 5.12.3 portable.
http://www.cpantesters.org/cpan/report/cd91ab56-6bf3-1014-831b-9f0412cd2d3c
Tk builds fine using the standard strawberry installation:
Hi,
yes, strawberry 5.12.3 portable has a bug related to $Config{libpth}
which causes Tk installation failure.
Solutions:
1/ for 5.12.3 try patch mentioned here
http://www.mail-archive.com/win32-vanilla@perl.org/msg00343.html
2/ for 5.14.2 try the latest portable beta/RC from here
http://strawberryperl.com/package/kmx/p5.14.2.1-RC/
--
kmx
Re: CPAN::Reporter and strawberry perl portable
On 20.11.2011 19:58, chm wrote:
It would be very convenient if Strawberry Perl
(portable and regular editions) included modules
needed for CPAN Testers submissions.
Whenever I set up a new strawberry perl portable
(SPP) sandbox for testing, I always have to
redo the install and update to support the new
metabase and CPAN::Reporter. One issue with
running CPAN::Reporter for test reports with SPP
is that the default directory seems to be set to
C:\.cpanreporter rather than a folder in the SPP
root directory.
Cheers,
Chris
Hi Chris,
there are basically 2 kind of issues
1/ troubles with Strawberry Portable Perl (SPP)
2/ bugs in CPAN::Reporter
As for 1/ there were a lot of changes during the last week(s) in SPP;
please take the latest beta from
http://strawberryperl.com/package/kmx/p5.14.2.1-RC/ for your testing (I
know that you prefer to have 5.12.x but we are currently focused only on
fixing 5.14 builds).
In the latest SPP the issue with C:\.cpanreporter should not happen any
more as in SPP the pseudo home directory is located in
portable_perl_root\data directory (providing that the module in
question uses File::HomeDir - which is the case of CPAN::Reporter).
The following works for me with the latest beta of SPP:
Let us have portable strawberry perl in z:\portable4testing
z:\portable4testing cpan -fi Task::CPAN::Reporter
z:\portable4testing mkdir z:\portable4testing\data\.cpanreporter\
z:\portable4testing metabase-profile -o
z:\portable4testing\data\.cpanreporter\metabase_id.json
z:\portable4testing cpan
cpan o conf init test_report
cpan o conf commit
cpan q
Now the troubles marked 2/ (CPAN::Reporter related)
*/ there are some failing tests - on the latest SPP 5.14.2.1-beta
t/03_config_file.t + t/70_darwin_move_config.t - which is the reason why
you need -fi for installation
*/ in theory it should be enough to run cpan o conf init test_report
just after Task::CPAN::Reporter installation (it calls
metabase-profile command automatically) however on my Windows box it
stucks at this point:
Would you like to run 'metabase-profile' now to create
'Z:\portable4testing\data\.cpanreporter\metabase_id.json'? [y]
Running [Z:\PORTAB~1\perl\bin\metabase-profile.BAT --output
Z:\portable4testing\data\.cpanreporter\metabase_id.json --email k...@cpan.org
--secret 123456789]...
Enter full name:
... where I am not able to enter the requested full name. Which is IMHO
an issue in CPAN::Reporter not SPP.
This is the reason for creating
z:\portable4testing\data\.cpanreporter\metabase_id.json manually before
running cpan o conf init test_report.
*/ the good news is that CPAN::Reporter does use File::HomeDir (not
$ENV{HOME} or $ENV{USERPROFILE}) which makes it portable-perl-friendly
To sum up: if you take the latest Strawberry Portable Perl beta it
should somehow work + I might be a good idea to report remaining
CPAN::Reporter issues to proper place.
--
kmx
Re: gcc for building Perl on WinXP
Hi Rob, Just getting to it now. (I know Chris has already established that the pthreads suport builds fine using his small patch to pthread.h. I'm building PDL-2.4.9_009, also with pthreads support as provided by 2), above - and also with Chris's amendment to pthread.h.) First thing I noticed with this Strawberry distro is that, as with most (all ?) Strawberry distros, there's no gfortran compiler. This means that the Slatec and Minuit parts of PDL won't get built. That's old news, and not all that critical - but I thought I should mention it anyway ;-) I know about that :) Apart from: http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip We have also prepared other PDL handy stuff - like: http://strawberryperl.com/package/kmx/32_gcctoolchain/mingw64-w32-gfortran4.4.7-pre_2001.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_gsl-1.15-bin_2004.zip http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_fftw-2.1.5-bin_20110506.zip It is only about decision how fat should strawberry perl be. Anyway you can unzip them into one directory and have a go. Apart from that, all looks good Unrelated to PDL, but the latest mpfr library (version 3.1.0) should build with TLS (Thread Local Storage) by default and straight out of the box. The version of the mpfr library that ships with Strawberry (version 3.0.1) was not built with TLS - which probably means that you didn't ask for it (--enable-TLS) when building the library. Mind you, I haven't checked that --enable-TLS will work for mpfr-3.0.1 on Windows, but 3.1.0 certainly provided TLS for me ... and without my asking.) No big deal - just thought I'd mention. On threaded perls, that TLS capability can be handy for Math::MPFR. Thanks for this notice, I will try to use --enable-TLS by the next mpfr-3.1+ rebuild (according ./configure --help it seems not to be available in 3.0.1). I noticed, too, that the mpc library that ships with Strawberry hasn't been built to accommodate the complex.h types (double _Complex and long double _Complex). From a perl point of view, this hardly matters at all because there's no way to natively pass these types to or from perl. I did slap together a Math::Complex_C module that wraps the complex.h types and functions, and thereby provides a gateway to passing these types to Math::MPC, but I doubt that anyone makes use of this capability anyway. Besides, Math::Complex_C can sometimes fail a test or two, generally because of compiler bugs (mainly in the form of incorrectly implemented functions). To enable this should I pass some extra option to mpc configure/make? -- kmx
Re: gcc for building Perl on WinXP
Yes, dmake clean did the trick. Thanks. -- kmx On 7.11.2011 22:32, Chris Marshall wrote: I just realized what might have happened. You'll need to do a dmake clean and then a complete build from scratch to ensure that old copies of the various files are not being used (some of these are generated at the configure stage). On Mon, Nov 7, 2011 at 4:20 PM, Chris Marshalldevel.chm...@gmail.com 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, kmxk...@atlas.cz 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, chmdevel.chm...@gmail.comwrote: 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, Sisyphussisyph...@optusnet.com.au wrote: - Original Message - From: kmx As for the future gcc-4.6.2 toolchain there is also an interesting question about including pthreads or winpthreads support as PDL is AFAIK somohow able to handle threads this way (not sure if this is valid for Win32) Yes, pthreads works with PDL on Win32. There's a crash in one of PDL's pthread test scripts that needs to be sorted out, but the basic functionality seems to be fine. Cheers, Rob - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1411 / Virus Database: 2092/4000 - Release Date: 11/06/11
Re: gcc for building Perl on WinXP
Chris and/or Rob, could you please try the following: 1/ take http://strawberryperl.com/package/kmx/p5.14.2.1-RC/strawberry-perl-5.14.2.1-portable-32bit-beta-1.zip 2/ take http://strawberryperl.com/package/kmx/32_libs/5.14-extras/32bit_pthreads-2.9.0-bin_2001.zip (unzip into the same dir as 1/) 3/ try to build PDL with pthreads support My quick test failed during PDL installation (but it was really a quick shot) Any feedback welcome -- kmx On 3.11.2011 14:13, Chris Marshall wrote: We've tested the PDL pthread support with POSIX Threads (pthreads) for Win32 at http://sourceware.org/pthreads-win32/ . It is nice because it allows PDL computations to make use of multicore processors for calculations. Always nice to see those factors of 2X, 4X, 6X, or more in speedup --Chris On Wed, Nov 2, 2011 at 9:30 PM, Sisyphussisyph...@optusnet.com.au 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
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 Mikokarel.m...@hotmail.com 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 supportinggccroot/include andgccroot/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 gccroot/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=detailaid=2886331group_id=202880atid=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 Mikokarel.m...@hotmail.com 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 supportinggccroot/include andgccroot/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
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
-LC:\chm\strawberry\perl_512_3_0\perl\lib\CORE
-LC:\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
-LC:\chm\strawberry\perl_512_3_0\perl\lib\CORE
-LC:\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\vendor\lib\Portable\Config.pm
portable.new\perl\vendor\lib\Portable\Config.pm
--- portable.orig\perl\vendor\lib\Portable\Config.pmWed Apr 13 02:20:12 2011
+++ portable.new\perl\vendor\lib\Portable\Config.pm Mon Oct 31 13:00:13 2011
@@ -32,7 +32,7 @@
and
length $conf-{$key
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.something-portable than new 5.12.whatever-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
-LC:\chm\strawberry\perl_512_3_0\perl\lib\CORE
-LC:\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
-LC:\chm\strawberry\perl_512_3_0\perl\lib\CORE
-LC:\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: 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
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: 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 inttypes.h 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
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
