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