After 9 months of hard work put in by the amazing Curtis Jewell, I'm happy to confirm that the Strawberry Perl is finally going ahead with the long-awaited switch-over from an .exe to a .msi installer.
Strawberry Perl July 2009 will be first release from the completely rewritten 4th generation distribution generator, built on the Microsoft Open Source WiX installer toolchain.
Does SP install Padre?
Re:dumb question?
Alias on 2009-07-17T12:54:22
No. Strawberry Perl remains true to it's original product design.
A distribution aimed at the 40% of Perl programmers that work primarily on Unix but at least once a year on Windows.
"A 100% Open Source CPAN-capable Perl for your Windows® computer that works exactly the same as Perl everywhere else."
After the core distribution release, however, you should expect to see a "Padre Standalone for Windows" type distribution that contains the strawberry core and adds Padre.
Re:dumb question?
mw487 on 2009-07-17T13:11:58
After the core distribution release, however, you should expect to see a "Padre Standalone for Windows" type distribution that contains the strawberry core and adds Padre.
That would be lovely, thanks. I seem to be an edge case, and can not get Padre working on any of my machines. YMMV.
Hi,
the following one-liner brings perl 5.10.0/Win32 to crash:
perl -e "use namespace::clean; fork;"
*) it is not an issue with perl 5.8.9/Win32
*) it is not specific to strawberry 5.10.0.6 July/09 (the same bug exists in all previous 5.10.0.*)
*) perls 5.10.0 for Linux/Cygwin do not suffer from this bug
*) I have investigated this bug a little bit and sent a couple of RTs:
RT - Perl::Dist::Strawberry
https://rt.cpan.org/Ticket/Display.html?id=45726
RT - Variable::Magic
https://rt.cpan.org/Ticket/Display.html?id=46546
RT - perl 5 core
http://rt.perl.org/rt3/Public/Bug/Display.html?id=66158
It seems to be a bug in fork implementation for Win32 (see the last post in the above mentioned RT - perl 5 core).
I know that it is not a new issue specific for strawberry Jul/09 release but I guess that you are much closer to perl 5/win32 core development team therefore you can be more successful in moving things forwards.
--
kmx
Re:perl-5.10.0.6 has broken fork
DiamondInTheRough on 2009-07-19T06:16:28
Tell you what - they're working on 5.10.1, and I've got a Strawberry-like build process that works for it.
I'll check if the bug still exists in the 5.10.1 snapshots with the command line you gave and let them know, but it may take a few days.
Re:perl-5.10.0.6 has broken fork
kmx on 2009-07-27T22:35:55
Any results from testing fork issue on 5.10.1?
--
kmxRe:perl-5.10.0.6 has broken fork
kmx on 2009-08-03T12:28:32
Hi,
I have compiled the latest dev release from perl5.git.perl.org and IT SUFFERS FROM THIS BUG.
--
kmxRe:perl-5.10.0.6 has broken fork
DiamondInTheRough on 2009-08-04T21:46:10
I was just going to test this today (I've finally got the computer time on my family's computer to build a 5.10.1 prerelease, among other things) - sounds like p5p needs bugged, and they received your last message on the bug yesterday, I think. (I'm on the list and reading it, and I don't know enough about the perl core to add strength to your proposed patch, although I will request that it be put in, at the latest, post-5.10.1-RC1.)
BTW: Did you test off blead, or off maint-5.10?
Re:perl-5.10.0.6 has broken fork
DiamondInTheRough on 2009-08-04T23:21:34
What I compiled was the -RC0, and it gives me the opportunity to debug using Visual Studio. *grin*
Yup, the problem is there.Re:perl-5.10.0.6 has broken fork
kmx on 2009-08-05T08:02:57
Thanks for involving in this issue.
--
kmxRe:perl-5.10.0.6 has broken fork
DiamondInTheRough on 2009-08-06T16:16:58
I did a compilation using last night's release, and the simple case doesn't crash.
C:\NewFolder>\perl\bin\perl.exe -e "use namespace::clean; fork; print qq{1\n}";"
1
1(test.pl being the script used in perl rt# 66158)
C:\NewFolder>\perl\bin\perl test.pl
After fork 1: 5524
After fork 2: -6120While Strawberry 5.10.0.6? Crashes both times.
(I should release a 5.10.1.0 beta 1 soon after it comes out.)
Hi,
DBD::MySQL and DBD::Pg pre-installed by default are nice however it is missing the crucial libraries LIBMYSQL.DLL and LIBPQ.DLL.
It becomes a problem if some other module detects e.g. DBD::MySQL as present and tries to use it - than an error dialogue (GUI) with a message about missing DLL pops up.
What was the original intention? Should all DLL be included in strawberry distribution or should the users get LIBMYSQL.DLL and LIBPQ.DLL get from somewhere else?
--
kmx
Re:MySQL and Postgress support
Alias on 2009-07-28T15:31:11
We had meant to include everything.
Re:MySQL and Postgres support
DiamondInTheRough on 2009-07-30T19:27:51
As Alias said, we meant to include everything.
Because of that, we had to make a quick decision to rebuild, and during that rebuild, pull the PostgreSQL support for the final.
The reason for that is explained at http://csjewell.dreamwidth.org/1710.html.
The MySQL client DLL is in the rebuild as of now, and it is uploaded to the URL's above.
Re:MySQL and Postgres support
kmx on 2009-07-31T06:47:54
Hi,
Firstly, thanks for the fix.
As I am not allowed to put comments on dreamwidth.org I put my feedback to libpq.dll issues here:
1) I agree that MSVCRT80.DLL (part of MS Visual C redistributables) is a problem and we cannot just simply copy this dll into strawberry distribution. On the other hand I do not understand why are the official Pg binaries built in this way - the only reason could be building Pg via MS Visual C/C++ Express edition that does not contain some static libraries and forces the developers to be dependant on VC redistributables. I am nearly 100% sure that it is possible (at least with MS Visual C/C++ standard edition or higher [unfortunately not free]) to build libpq.dll without MSVCRT80.DLL dependency. The other way that I have successfully used some time ago is to build libpq.dll (and corresponding *.a) with mingw (you will need MSYS environment) and to install DBD::Pg from cpan.
To sum up - getting rid of MSVCRT80.DLL means not to use official binary but to build a new one. We have 2 options:
- MS Visual C/C++ (see comment above)
- mingw (in MSYS environment)It would be pleasure for me to help you with this.
2) Including LIBEAY32.DLL/SSLEAY32.DLL (part of OpenSSL) will be probably feasible (I did not check the licence agreement) but as a fall-back we can build libpq.dll without ssl support (I would not prefer this but still better than no Pg support at all).
3) In case of including LIBEAY32.DLL/SSLEAY32.DLL I would appreciate to also include Net::SSLeay into standard strawberry distribution or to include also openssl's *.h/*.a to be able to install Net::SSLeay from cpan. I have quite positive experience with getting Net::SSLeay work on Win32.
--
kmxRe:MySQL and Postgres support
DiamondInTheRough on 2009-08-04T22:02:45
Can I have you hold up for just a bit before you go and build a MingW PostgreSQL for me? (We're now talking October release, so we have some time to decide.) I'll need to check on whether we want to include ssl or not.
When you do build it, and if we say yes on building OpenSSL into it, if you could build it against the Shining Light Productions compilation of OpenSSL (it includes MingW libraries), it'd be much appreciated.
If we decide to go the OpenSSL-including route, I'd like to be able to build everything against the same OpenSSL, and once SL's OpenSSL is installed, I've had NO problems with building Net::SSLeay on Strawberry myself.
:) Re:MySQL and Postgres support
DiamondInTheRough on 2009-08-04T22:14:17
Cancel that. DON'T use Shining Light - I forgot they have a dependency on MSVCR90.DLL - even worse! (We're trying to keep dependencies to MSVCRT.DLL only - not the versioned variants, so the gnuwin32 version probably won't work, either. That and it's out of date.)
We'll probably have to build OpenSSL from scratch, too.
Re:MySQL and Postgres support
kmx on 2009-08-05T07:59:52
Hi,
of course I will be happy to help you with building Pg support. In fact I have already done it for myself.
My approach is based on the following:
1) OpenSSL - I am currently using Shining Light but you are right that they are dependant on MSVCR90.DLL. I do not expect any problems rebuilding these DLLs - I have done it in one of our projects some time ago (both mingw and ms sdk compiler).
2) For bulding postgress I am using msys enviroment
- get http://downloads.sourceforge.net/mingw/msysCORE-1.0.11-bin.tar.gz
- unzip into c:\msys
- run c:\msys\postinstall\pi.bat and answer that your mingw is c:\strawberry\c3) Bulding Pg is quite easy:
- unpack Pg source files
- run: c:\msys\msys.bat and cd into Pg source dir
- run:./configure --with-openssl --with-ldap
- then: make install4) Copy dev libs/headers from c:\msys\local\pgsql into your strawberry
- c:\msys\local\pgsql\bin\pg_config.exe -> c:\strawberry\c\bin
- c:\msys\local\pgsql\lib\libpq.dll -> c:\strawberry\c\bin
- c:\msys\local\pgsql\lib\libpq.a -> c:\strawberry\c\lib
- c:\msys\local\pgsql\include\* -> c:\strawberry\c\includeLIBPQ.DLL has following dependecies:
c:\windows\system32\advapi32.dll
c:\windows\system32\kernel32.dll
c:\windows\system32\msvcrt.dll
c:\windows\system32\secur32.dll
c:\windows\system32\shfolder.dll
c:\windows\system32\wldap32.dll
c:\windows\system32\wsock32.dll
c:\strawberry\c\bin\ssleay32.dll
c:\strawberry\c\bin\libeay32.dllUnfortunately I was not able to include GSSAPI + Kerberos5 support into LIBPQ.DLL (in fact I do not use it and therefore have not tried so much).
5) Now simply: cpan DBD::Pg
So open questions:
- openssl rebuild - mingw or ms compiler?
- what about gssapi and krb5 support in libpq.dll - can we live without it?--
kmxRe:MySQL and Postgres support
DiamondInTheRough on 2009-08-05T10:52:58
Your first question: Preferably mingw, so we get the
.a files for free. If not, then msvc with /MT instead of /MD (use the static MSVCRT instead of having a dep on MSVCR90.DLL and friends - this will require a non-Express version) and we can use pexports and company to generate a .a for us, if a .lib isn't there at the end to be renamed. As for your second question, I think we can live without it, but I want a second opinion.
