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
June 9, 2013 19:39
RE: Include the Win32 extension in the ALL_STATIC build on Win32
Message ID:
> 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 
> 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:


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.

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