[Python-Dev] Static builds on Windows (original) (raw)
Thomas Heller theller at python.net
Wed Jul 28 22:00:32 CEST 2004
- Previous message: [Python-Dev] Static builds on Windows
- Next message: [Python-Dev] Static builds on Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"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 PyNOENABLESHARED, 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 another one.
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 would work
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.
Thomas
- Previous message: [Python-Dev] Static builds on Windows
- Next message: [Python-Dev] Static builds on Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]