Front page | perl.perl5.porters |
Postings from June 2013
On Fri, Jun 7, 2013 at 3:48 PM, Steve Hay <steve.m.hay@googlemail.com> wrote: > The last-but-one thing to do is to arrange for init_Win32CORE to be > exported from perl-static.exe (as it already is from perl519.dll, courtesy > of makedef.pl) otherwise GetProcAddress() won't find it. I see no harm in > always specifying __declspec(dllexport) in Win32CORE.c (except in one > existing Cygwin case which doesn't want it, which I'm not touching to > minimize regression risk). I thought that the .def file entry written by > makedef.pl for perl519.dll would then become redundant, and whilst the VC++ > build worked fine without it, the MinGW build didn't: init_Win32CORE no > longer got exported from perl519.dll, thus breaking the normal build, so > I've therefore left makedef.pl alone. The problem is that MinGW is exporting the decorate name via __desclspec(dllexport) while VC is exporting the undecorated on, making this mechanism somewhat useless for cross-compiler support. You may get things working by using the --kill-at and --enable-stdcall-fixup linker options, but I remember that it doesn't really work for all cases; you still end up with an additional underscore prefixed to symbols in MinGW or something like that. I have never been able to properly export symbols in VC compatible manner from MinGW without a .def file. I would expect the same problem for a static build using MinGW, so I don't think just using __declspec(dllexport) in Win32CORE will work in that case, but please let me know if I am wrong! > The very last thing to do in some future change is to improve the > ALL_STATIC build so that Win32 functions like CopyFile() do not go > through Win32CORE's w32_CORE_all forwarding function as they currently do: > it isn't necessary when Win32 is statically linked as well! I will revisit > this part very soon... I don't see a compelling reason to complicate things, as Win32CORE.c is a pretty small file. And only the very first call to any of the predefined Win32::* functions will go through the wrapper: the wrapper will effectively execute "require Win32" which will overwrite all the wrapper pointers with the real addresses, and then re-dispatch the current call to the newly initialized function. Cheers, -JanThread Next