Sisyphus wrote:
----- Original Message -----
From: "Robert May"
.
.
Steps to invoke problem:
(1) run: h2xs -A -n SomeModule
(2) cd into the created SomeModule directory
(3) run the incantation:
perl -MConfig_m Makefile.PL
nmake
nmake test
Generally this works fine, and the (one) test passes, but if
'SomeModule' is 'DropFile' or 'DropFiles' I get the following test
result (re-formatted for readability:
C:\Perl\5.8.7\bin\perl.exe "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib\lib', 'blib\arch')" t\DropFiles.t
# Failed test (t\DropFiles.t at line 9)
# Tried to use 'DropFiles'.
t\DropFiles....NOK 1#
Error: Can't load
'C:\WINDOWS\Desktop\xs_test\DropF\DropFiles\blib\arch/auto/DropFiles/DropFil
es.dll'
for module DropFiles: load_file:The operation completed successfully at
C:/Perl/5.8.7/lib/DynaLoader.pm line 230.
The problem disappears if I compile with
VC6, making me think in more likely to be a MinGW issue, but I'd like to
be able to build with MinGW without choosing a different module name.
Are you using the same 'nmake' in both instances ? (If so we can rule
'nmake' out as the culprit.)
Yes (double checked).
I can't reproduce the problem - though I haven't got exactly the same
environment - Windows2000, using 'dmake', gcc-3.4.4, AS build 810. However,
I can't see that any of those differences account for the strange behaviour
you're getting. (My immediate thoughts were that you must be doing something
silly - though, of course, that's not necessarily so - and I can't for the
life of me think of what that "silliness" could possibly be :-)
I've now tried it one win2k, and can't reproduce the problem there
either (with an almost identical setup).
I was hoping that I was doing something silly, and that posting to the
world would reveal what it was. I've spent a long time on this one now,
but I do seem to be getting somewhere.
I'd create 2 separate directories for the creation of DropFiles - one for
creating with MinGW/EU::FC, and one for creating with VC6. Then compare the
2 generated DropFiles.c. (Maybe also compare some of the other files - eg
the Makefile that was generated in both cases.)
Somewhere there has to be a difference that matters.
Nice idea. Source is identical. Makefiles, obviously, aren't
identical, but to the best of my knowledge the differences can be
justified and won't cause any issues.
What happens if you name the module (successively) DropFile, DropFil, Drop,
...., Dr, D ? At what point does the problem go away ?
A series of tests:
Drop - ok
DropF - fails
AropF - fails
DropFi - fails
DropFile - fails
DropFiles - fails
DropX - fails
DropFx - fails
DropFilesx - fails
xDropFiles - ok
Win32::DropF - fails
Win32::xDropF - ok
Appears to indicate that any module whose last component name starts
with 'DropF' fails. Interesting, but doesn't get me much closer to a
solution.
So I set about with the perl source code, and now understand a large
amount of the internals of DynaLoader. Looking at where the failure
appeared to be happening, and tracing throw the perl source
(win32/win32.c and win32/dl_win32.xs mainly) the failure appeared to be
comming from a LoadLibrary() call.
So I took 2 dlls produced by the above process, both compiled and linked
in the same way with gcc; one that works (DropX.dll) and one that
doesn't (DropF.dll), and wrote a simple perl script to attempt to
load them using LoadLibrary() directly (using Win32::LoadLibrary()).
DropX.dll loads fine; DropFiles.dll fails (returns '0' as a handle),
but the LoadLibrary call does not SetLastError, resulting in any call to
GetLastError returning 0; 0 is interpreted as NO_ERROR, hence the
mis-leading error message from DynaLoader.
So this appears to be a mingw or windows api issue, and not a problem
with DynaLoader.
Now I just need to find out what the difference is between the 2 dll's.
MS's Dependency walker (Depends.exe, comes with the platform SDK)
loads both fine, and doesn't reveal anything very useful, but a binary
diff of the 2 files (which are, incidently, exactly the same size) shows
areas of significant difference. I have no idea if this is expected or
not, but my gut feeling is that it is suspicious.
Off to find a mingw forum/list.
Thanks for your help.
Regards,
Rob(M).
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
