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

Re: dmake can't find config.h, and collector throws error when tryingtocompile perl-static.exe (perl-5.18.0 / mingw / 32b)

Thread Previous | Thread Next
From:
bulk88
Date:
June 7, 2013 01:08
Subject:
Re: dmake can't find config.h, and collector throws error when tryingtocompile perl-static.exe (perl-5.18.0 / mingw / 32b)
Message ID:
51B13275.8050506@hotmail.com
Steve Hay wrote:
> On 6 June 2013 19:10, Jan Dubois <jand@activestate.com> wrote:
>> Win32 is "special" because many of it's Perl level functions are
>> pre-defined (even without a "use Win32" statement), while the
>> implementation is in a dynamically linked module. This is done via the
>> statically linked Win32CORE wrapper that will load Win32 on demand.
>>
>> The problem here is that Win32CORE is not included in miniperl, so the
>> initialization code has to be called dynamically:
>>
>> In Perl_init_os_extras in win32/win32.c:
>>
>>     /* Initialize Win32CORE if it has been statically linked. */
>> #ifndef PERL_IS_MINIPERL
>>     void (*pfn_init)(pTHX);
>>     pfn_init = (void
>> (*)(pTHX))GetProcAddress((HMODULE)w32_perldll_handle,
>> "init_Win32CORE");
>>     aTHXa(PERL_GET_THX);
>>     if (pfn_init)
>>         pfn_init(aTHX);
>> #else
>>
>> The w32_perldll_handle is intialized during DLL_PROCESS_ATTACH in the
>> DllMain() function in win32/perllib.c, which will not be called when
>> perllib.c is part of an .exe file and not in a .dll.
>>
>> So you may want to modify Perl_init_os_extras to something like this:
>>
>>     void (*pfn_init)(pTHX);
>>     HMODULE module = (HMODULE)((w32_perldll_handle == INVALID_HANDLE_VALUE)
>>                                 ? GetModuleHandle(NULL)
>>                                 : w32_perldll_handle);
>>     pfn_init = (void (*)(pTHX))GetProcAddress(module, "init_Win32CORE");
>>
>> This should be safe even for miniperl, because pfn_init() is only
>> called when it isn't NULL.
>>

I like the "#ifndef PERL_IS_MINIPERL". Please dont remove it.

> 
> Thanks for waking me up to this. I've just pushed some changes
> containing most of what I've done so far since it does fix the
> original problem here of not being able to do a static build with
> MinGW at all.
> 
> The main problem remaining is that if I include Win32 in the static
> build then the pre-defined Win32 functions are not getting their
> implementations loaded on-demand, but since Win32 is currently
> excluded from the full static build anyway because of some other
> perceived problem (which I'm either missing or has since gone away)
> there was no reason to hold off what I've done so far.

I agree, it makes no sense for Win32CORE and Win32 to be in the same 
static build executable. Indirection and bloat. Something I think would 
have to be written for Win32 to do a series of NewXSes for the 
backcompat builtins, or Win32CORE's init_Win32CORE needs to have an def 
whether its a static build or a dynamic link build. If static def, then 
use fnc symbols from Win32::'s obj file instead of the w32_CORE_all 
stub/forwarding fnc.

> 
> I would still like to get Win32 working, though, so I've tried your
> above suggestion with the attached patch (which also incorpoates your
> other suggestion of removing DEFAULT_BINMODE), but it still gives me
> the same error.
> 
> A simple "perl-static.exe -e "Win32::CopyFile()"" normally gives the
> expected "usage: ..." error, but instead still gives me an error about
> Win32::CopyFile being undefined. It works if I add -MWin32 to the
> command-line, though, so it is indeed this on-demand loading which is
> broken in the static build.

I guess as others in this thread said, init_Win32CORE never ran.

> 
> I made a debug build of it and stepped into Perl_init_os_extras. The
> 'module' variable is set to something sensible, but 'pfn_init' comes
> back NULL. It's unusual to call GetProcAddress on an .exe. I believe
> it should work, but I think the function needs to be exported from the
> .exe? It currently isn't (only a few PerlIO_* functions,
> Perl_win32_init/term, RunPerl and numerous win32_* functions are,
> according to dumpbin /exports), so I'll have to look at that; not sure
> where the best place to arrange for it is at the moment.

The GetProcAddress is there as a quick fix for a perl packager problem 
many years ago 
http://perl5.git.perl.org/perl.git/commit/9fb265f7d587e571375a3a5fdb05c24fd9d10d91?f=win32/win32.c 
. I havent had the time to ever persue turning that GetProcAddress into 
macros or fixing PAR Packer.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About