Front page | perl.perl5.porters |
Postings from June 2013
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