develooper Front page | perl.perl5.porters | Postings from June 2013

Re: Include the Win32 extension in the ALL_STATIC build on Win32

Thread Next
Jan Dubois
June 7, 2013 23:12
Re: Include the Win32 extension in the ALL_STATIC build on Win32
Message ID:
On Fri, Jun 7, 2013 at 3:48 PM, Steve Hay <> 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 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
> 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 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.


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About