Thomas Heller wrote:
> I'm lost in these symbols. It seems, the DL_EXPORT symbol is already
> deprecated, and public functions should be, and are, declared
> PyAPI_FUNC.
That might well be. My reference to DL_EXPORT was from memory, and I
was too lazy to look up the current macro usage. Looking again.
> OTOH, the only way to define PyAPI_FUNC as
> __declspec(dllexport) is to define Py_ENABLE_SHARED and Py_BUILD_CORE.
> And isn't Py_ENABLE_SHARED mutually exclusive with Py_NO_ENABLE_SHARED?
Right. Why again did you want to define Py_NO_ENABLE_SHARED? I would
think that you can define it and still build a static library.
> Which makes the exe slightly larger, because of the import table
> section. I have yet to figure out if extensions can link to these
> functions - normally they expect the functions in the pythonxy.dll
> module, and not in the (say) python_static.exe.
Yes. You will need to provide an import library for the final
executable, and you need to call this import library python24.lib.
Then, extensions should pick it up automatically through the
#pragma comment.
Existing binary extensions are not affected - although it might
be possible to provide a stub python24.dll which reexports all
symbols from <interpreter>.exe. This would be needed only if
extension modules are needed.
If you want to disable dynamic loading at run-time, you could offer
a patch that allows to disable dynamic loading - either at the C
API or even exposed to Python. One implementation of this function
could garble _PyImport_Filetab, replacing certain entries with
SEARCH_ERROR, e.g. through
PyImport_DisableExtension(".pyd");
Re-enabling a disabled extension is probably not needed.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4