Repository navigation
SOABI for debug version of Python 3.13 on Windows #125591
Description
Bug report
Bug description:
The SOABI configuration variable is 'cp313-win_amd64' for both debug and release builds of Python 3.13 on Windows.
>>> import sysconfig
>>> sysconfig.get_config_var('SOABI')
'cp313-win_amd64'Is this intentional, or should the value be 'cp313d-win_amd64' for the debug build of Python? On Linux, the value for SOABI has the d flag in the debug build of Python.
>>> import sysconfig
>>> sysconfig.get_config_var('SOABI')
'cpython-313d-x86_64-linux-gnu'I ask because setuptools uses the value for SOABI to derive the ABI tag when building a wheel, and the d flag is missing when building a wheel containing an extension module using the debug build of Python 3.13. We want to know whether it should be setuptools's responsibility to add the d flag or whether the d flag should already be part of SOABI to begin with. For reference, the setuptools bug report is at pypa/setuptools#4674.
CPython versions tested on:
3.13
Operating systems tested on:
Windows
Activity
colesbury commentedon Oct 16, 2024
I think I added
sysconfig.get_config_var('SOABI')for Windows in:In particular, the relevant comments are here: #110049 (comment).
The problem is that Windows uses a different format and the
_dtag isn't part of what we internally consider the SOABI. Debug libraries look like:where
cp313-win_amd64is the SOABI and the_dtag is attached to the name.cpython/Include/internal/pycore_importdl.h
Lines 122 to 128 in 760872e
zooba commentedon Oct 16, 2024
Yeah, the filename format is just different. Looking at
sysconfig.getconfigvar("EXT_SUFFIX").startswith("_d")might be the most relevant Windows-specific check, or just do whatpackaging.tagsdoes (which might be nothing, meaning there are no debug-specific wheels for Windows).IMHO, debug builds of CPython aren't worth supporting to the point where I'd put wheels on PyPI. Is there a new use case here that I haven't heard about? Or are we just looking for 100% completeness where it isn't really useful?
adang1345 commentedon Oct 16, 2024
I have a project where during development, I use
setuptoolsto create a wheel containing a debug build of an extension module and is specific to the debug build of Python. The wheel is named something likeexample-1.0.0-cp312-cp312d.whl, which I then install using the debug build of Python. I find that doing this makes the extension module easier to debug.With Python 3.12,
SOABIon Windows is empty, sosetuptoolsuses its own logic to construct the ABI tagcp312dif the debug build of Python is used. With Python 3.13, now thatSOABIis set,setuptoolsdoes something different; it takes theSOABIvalue ofcp313-win_amd64and uses the part before the hyphen,cp313as the ABI tag. This misses thedflag when the debug build of Python 3.13 is used. I was trying to figure out whether a change should be made to CPython orsetuptools.Based on the above comments, it's clear that
setuptoolsshould make a change. Thanks!zooba commentedon Oct 16, 2024
The critical compiler flag is
/MDd(vs/MDfor a non-debug build), which makes you require the CPython debug ABI.If you pass
/MD, even with debug info turned on and optimisations turned off, you get the regular ABI but with an easily debuggable extension module. The only thing you lose is native assert() statements and some debugging features of the C runtime (which are partially controlled by the_DEBUG/NDEBUGpreprocessor variables, which are automatically set by/MDd//MDbut often specified manually which can become problematic).Using a debug build of CPython is only really necessary to debug CPython itself. If you believe that CPython does not contain the bug, you don't need its debug build.
adang1345 commentedon Oct 17, 2024
Thanks, that's good to know. However, a complication is that my extension module links to a DLL which exports C++ functions, and I'm building that DLL using
/MDdbecause I often debug into that DLL's code as well, and I like the memory management checks that/MDdprovides in the DLL. To ensure C++ ABI compatibility, the extension module must also be built with/MDd. I suppose my options then are to build both the extension module and the DLL with/MDdand continue to use the debug build of CPython, or build both the extension module and DLL with/MD.