Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SOABI for debug version of Python 3.13 on Windows #125591

Closed
adang1345 opened this issue Oct 16, 2024 · 5 comments
Closed

SOABI for debug version of Python 3.13 on Windows #125591

adang1345 opened this issue Oct 16, 2024 · 5 comments
Labels
OS-windows type-bug An unexpected behavior, bug, or error

Comments

@adang1345
Copy link
Contributor

adang1345 commented Oct 16, 2024

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

@adang1345 adang1345 added the type-bug An unexpected behavior, bug, or error label Oct 16, 2024
@colesbury
Copy link
Contributor

colesbury commented 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 _d tag isn't part of what we internally consider the SOABI. Debug libraries look like:

foo_d.cp313-win_amd64.pyd

where cp313-win_amd64 is the SOABI and the _d tag is attached to the name.

#ifdef PYD_PLATFORM_TAG
# define PYD_SOABI "cp" Py_STRINGIFY(PY_MAJOR_VERSION) Py_STRINGIFY(PY_MINOR_VERSION) PYD_THREADING_TAG "-" PYD_PLATFORM_TAG
#else
# define PYD_SOABI "cp" Py_STRINGIFY(PY_MAJOR_VERSION) Py_STRINGIFY(PY_MINOR_VERSION) PYD_THREADING_TAG
#endif
#define PYD_TAGGED_SUFFIX PYD_DEBUG_SUFFIX "." PYD_SOABI ".pyd"

@zooba
Copy link
Member

zooba commented 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 what packaging.tags does (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
Copy link
Contributor Author

adang1345 commented Oct 16, 2024

I have a project where during development, I use setuptools to 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 like example-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, SOABI on Windows is empty, so setuptools uses its own logic to construct the ABI tag cp312d if the debug build of Python is used. With Python 3.13, now that SOABI is set, setuptools does something different; it takes the SOABI value of cp313-win_amd64 and uses the part before the hyphen, cp313 as the ABI tag. This misses the d flag when the debug build of Python 3.13 is used. I was trying to figure out whether a change should be made to CPython or setuptools.

Based on the above comments, it's clear that setuptools should make a change. Thanks!

@zooba
Copy link
Member

zooba commented Oct 16, 2024

The critical compiler flag is /MDd (vs /MD for 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/NDEBUG preprocessor variables, which are automatically set by /MDd//MD but 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
Copy link
Contributor Author

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 /MDd because I often debug into that DLL's code as well, and I like the memory management checks that /MDd provides 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 /MDd and continue to use the debug build of CPython, or build both the extension module and DLL with /MD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OS-windows type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants