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:
cygcheck
/usr/lib/perl5/site_perl/5.8.2//cygwin-thread-multi-64int/auto/Win32/OLE/OLE.dll
C:/cygwin/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int/auto/Win32/OLE/OLE.dll
C:\cygwin\bin\cygwin1.dll
C:\WINNT\system32\ADVAPI32.DLL
C:\WINNT\system32\NTDLL.DLL
C:\WINNT\system32\KERNEL32.DLL
C:\WINNT\system32\RPCRT4.DLL
C:\WINNT\system32\OLE32.dll
C:\WINNT\system32\GDI32.dll
C:\WINNT\system32\USER32.DLL
C:\WINNT\system32\OLEAUT32.DLL
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.
--Jeremy
P.S. After reverting to 5.8.2, the cygcheck output looks like this:
C:/cygwin/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int/auto/Win32/OLE/OLE.dll
C:\cygwin\bin\cygwin1.dll
C:\WINNT\system32\ADVAPI32.DLL
C:\WINNT\system32\NTDLL.DLL
C:\WINNT\system32\KERNEL32.DLL
C:\WINNT\system32\RPCRT4.DLL
C:\WINNT\system32\OLE32.dll
C:\WINNT\system32\GDI32.dll
C:\WINNT\system32\USER32.DLL
C:\WINNT\system32\OLEAUT32.DLL
C:\cygwin\bin\cygperl5_8_2.dll
C:\cygwin\bin\cygcrypt-0.dll
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.
--
Jeremy Impson
Senior Network Security Engineer
Lockheed Martin Systems Integration-Owego
email: [EMAIL PROTECTED]
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
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
