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
From:
Steve Hay
Date:
June 8, 2013 00:03
Subject:
Re: Include the Win32 extension in the ALL_STATIC build on Win32
Message ID:
CADED=K7qRWc9teDS-k8SxuPLxg9D+T4jb=rU_T1N4ttpG4QODw@mail.gmail.com
On 8 June 2013 00:11, Jan Dubois <jand@activestate.com> wrote:
> 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!
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 makedef.pl 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
init_Win32CORE.
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