>> I.e. even with the change, it would *still* depend on objimpl.h >> (and other) settings what ABI this debug DLL exactly has. >> > I think it does. My proposal was perhaps not clear: For existing > python versions, always export _PyObject_DebugMalloc et al. Hmm. That's still not clear. What are "existing Python versions"? You can't change them anymore; any change can only affect future, as-of-yet-non-existing Python versions. Also, what do you mean by "always"? Even in release builds? Would this really help? You shouldn't be mixing PyObject_DebugMalloc and PyObject_Malloc in a single process. > On new python versions, remove the > _PyObject_DebugMalloc from the ABI. Make the switch internal to > obmalloc.c, so that you can turn on the debug library by recompiling > pythonxx_d.dll only (currently, you have to recompile the .pyd files > too!) That sounds fine. >> But there are tons of ABI changes that may happen in a debug >> build. If you want to cope with all of them, you really need to >> recompile the source of all extensions. > Are there? Can you give me an example? If you define Py_TRACE_REFS, every object has two additional pointers, which aren't there if you don't. So extensions compiled with it are incompatible with extensions compiled without it. If you define COUNT_ALLOCS, every type object will have additional slots; again, you can't mix extensions that have a different setting here than the interpreter. 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