This is the mail archive of the
mailing list for the Cygwin project.
Perl 5.8.5 and libwin32 0.191-1 incompatibility
- From: "Impson, Jeremy" <jeremy dot impson at lmco dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 12 Oct 2004 15:17:26 -0400
- Subject: Perl 5.8.5 and libwin32 0.191-1 incompatibility
Hello, and FYI:
I updated Perl to version 5.8.5-3 from 5.8.2-1, and found that my Perl scripts can no longer find the Win32 Perl modules. The libwin32 0.191-1 package is installed, but is put in /usr/lib/perl5/site_perl/5.8.2, whereas Perl 5.8.5 looks only in /usr/lib/perl5/site_perl/5.8.5. (Perl uses its @INC variable to control what directories it uses to load modules from.)
So I put /usr/lib/perl5/site_perl/5.8.2 in the @INC (using "use lib") of my Perl script, ran it, and got a Win32 error number 126 (sorry, I forgot to capture the exact text), which led to this discovery:
Error: could not find cygperl5_8_2.dll
So it turns out that the OLE (and probably other) parts of the Win32 perl module are linked to cygperl5_8_2.dll, which got removed when I upgraded 5.8.5. The announcement for 5.8.5 (http://sources.redhat.com/ml/cygwin/2004-08/msg00774.html) states that it should be binary compatible with 5.8.2 (and I do not doubt this), but if the the binary portions of any old module are linked against cygperl5_8_2.dll, then binary compatibility is somewhat of a moot point.
I tried using CPAN's version of Win32::OLE, which I believe was developed by ActiveState, but got a lot of compile errors, and I came to the conclusion that the cygwin package is a patched version of what's on CPAN. Is this correct?
So for now I reverted back to 5.8.2. A better solution is to rebuild libwin32 against 5.8.5. The best would be to figure out a way to make the modules a bit more independent of the version changes, if possible.
I recall that, the last time I compiled Perl (years ago under Linux), you could tell the configurator to build Perl so that it checks the module directories of old Perl installations if it fails to find the module in the current module dirs. (E.g. if there's no version for 5.8.5, fall back to those for 5.8.2.) This still wouldn't fix the absence of cygperl5_8_2.dll. One could keep old versions of cygperlX_Y_Z.dll around when upgrading, but I suspect that you couldn't have the same Perl process load both versions of the DLL due to symbol conflict.
Would renaming cygperlX_Y_Z.dll to cygperlX_Y.dll break anything? I assume the Perl tries to be binary compatible at the "Y" level of version "X.Y.Z". If so, then this scheme would allow older binary modules to link (and maybe even work!) against newer Perl installations. We'd still have to recompile every module currently linked against the one named cygperlX_Y_Z.dll, but only one time, not every upgrade. (Until X.Y+1 comes out.)
Any thoughts? Please CC: me as I am not on the list. Thanks.
P.S. After reverting to 5.8.2, the cygcheck output looks like this:
I'm not including the output of cygcheck -vs in this message, because I don't think it's helpful in this case. If anyone thinks otherwise, please let me know and I will gladly provide it.
Senior Network Security Engineer
Lockheed Martin Systems Integration-Owego
phone: 607 751 5618
cell: 607 765 7630
fax: 607 751 6025
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html