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

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

Thread Previous | Thread Next
Steve Hay
June 8, 2013 00:03
Re: Include the Win32 extension in the ALL_STATIC build on Win32
Message ID:
On 8 June 2013 00:11, Jan Dubois <> wrote:
> 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!

I must admit I was expecting __declspec(dllexport) not to work for
perl-static.exe after finding that using only that (with no .def file
entry) had broken perl519.dll, but it strangely does work.

I've just double-checked my results with two fresh builds, both with
ALL_STATIC=define (that builds a regular
perl.exe+perl519.dll+perl519.lib as well as the extra
perl-static.exe+perl519s.lib) -- one using current bleadperl (i.e.
with the changes that I just committed), and the other having those
changes plus the extra change that I thought I could get away with to
remove "try_symbols("init_Win32CORE") if $static_ext =~
/\bWin32CORE\b/;" from too.

The current bleadperl build has a working perl.exe+perl519.dll and a
working perl-static.exe. Examining the output of (VC++'s) dumpbin
/exports shows that both perl519.dll and perl-static.exe are exporting

The build with init_Win32CORE removed from perldll.def, however, has a
broken perl.exe+perl519.dll as far as the Win32 module is concerned,
but perl-static.exe is still fine, of course, since it doesn't use a
.def file anyway. Dumpbin /exports shows that this perl519.dll doesn't
export init_Win32CORE but perl-static.exe does!

So it seems that __declspec(dllexport) alone does work for an .exe but
not for a .dll!

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