Front page | perl.perl5.porters |
Postings from June 2013
> From: bulk88
> Yes, but, using GetProcAddress is a hack. All function calls
> within the
> same binary should be static linked. BUT, to implement static
> XS linking
> Dynaloader does hook GetProcAddress on Dynaloader's public
> perl API side
> at
> http://perl5.git.perl.org/perl.git/blob/HEAD:/ext/DynaLoader/d
> l_win32.xs#l68
> and checks with a static list in the perl binary whether a
> module exists
> as static linked XS before going to the OS's DLL loader.
looking into this function, dl_static_linked, makes me think
it should be adjusted to be less hacky,
we generate this "staticlinkmodules", and can make things
easier for dynaload, by design.
Another thing bothers me a little:
currently XS extension depends on perlXY.dll
D:\perl-tests\perl-5.18.0\lib\auto\B>dumpbin /dependents B.dll
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file B.dll
File Type: DLL
Image has the following dependencies:
perl518.dll
MSVCRT.dll
KERNEL32.dll
in "all-static" case, there will be "perl-static.exe" instead of perl518.dll
doing it other way round - be dependant on EXE that is exporting
functions in a DLL-like way.... is it indeed possible?
Should it contain DllMain function??
OS loader will not load another instance of EXEcutable?
If all this possible, this needs edits in MakeMaker...
Yet, special permission is needed to make adjustments into that module.
Before that, I need to see a hello-world program that answers my question,
or maybe write my own.
Regards,
Vadim.
Thread Previous
|
Thread Next