[Python-Dev] Static builds on Windows
theller at python.net
Wed Jul 28 22:00:32 CEST 2004
"Martin v. Löwis" <martin at v.loewis.de> writes:
> Thomas Heller wrote:
>> Now, shouldn't the definition of this symbol be protected by #ifndef
>> Py_NO_ENABLE_SHARED, or is there already a different mechanism (without
>> the need to change the source files)?
> Perhaps. However, my understanding is that it is, in principle, possible
> to provide dynamic loading even if the interpreter is all in a single
> static python.exe. IOW, people sometimes claim that you can link against
> an .exe, in which case you could have extension modules build for your
> static interpreter, which could then be loaded dynamically.
> I don't know whether anybody has tried that recently, or whether it is
> worth supporting.
I have never tried that, although I've heard that it wouldn't work.
> If not, I would have no problems claiming that dynamic
> loading is unavailable for a static build.
Currently, it does *not* work, so I think it would be good to add the
above protection in the header file. It can be removed (or extended), as
soon as someone makes it work.
> As for dynamic detection of the issue: I thought there was a mechanism
> somewhere which tries to find out whether an extension module is linked
> against the "wrong" .dll. Perhaps that mechanism could be extended to
> support static libraries: Find out what the module name is of the module
> containing importdl.obj, and refuse loading if the extension module
> is linked with a different PE module.
Yes there is, in Python/dynload_win.c. But IIRC it works by hardcoding
the name of the python dll. And it is wasteful to try this all the time
if it is known in advance that it cannot succeed.
Maybe it would be best to replace this module for the static build by
Ok, three options:
- make the patch I suggested to the header file.
- patch dynload_win.c in the way you suggested.
- ignore the whole issue, and replace dynload_win.c for static builds
by another file.
- investigate if back linking from extension modules to the exe file
Related to this issue: Would it be a good idea to add a project to the
MSVC workspace which builds a static library? This could either be used
directly, or as a staring point for customization.
More information about the Python-Dev