Repository navigation
PyMODINIT_FUNC does not apply __declspec(dllexport) on Windows #141671
Description
Activity
I filed a setuptools issue: pypa/setuptools#5118
I personally think this would be safe to be backported to 3.12, 3.13, 3.14 as adding
__declspec(dllexport)toPyMODINIT_FUNCdoes not break anything.Also then the setuptools patch would also apply to those versions of python as well when they upgrade the package.
This is because currently what I do to work around this was to
#undef PyMODINIT_FUNC #if defined(__cplusplus) #define PyMODINIT_FUNC extern "C" Py_EXPORTED_SYMBOL PyObject* #else /* __cplusplus */ #define PyMODINIT_FUNC Py_EXPORTED_SYMBOL PyObject* #endif /* __cplusplus */
in my C extension code which I feel could have been avoided entirely.
- added a commit that references this issue
on Jan 7, 2026 I'd rather let this change have the full alpha/beta period before it hits production. It's old, platform-specific, widely used, and tied to build systems.
Reacted by Ralf GommersSetuptools, and historically distutils, does (2) -- and so does, presumably, any other build system for native extensions on Windows.
For clarity: I think you meant that
setuptools/distutilsdoes (3), not (2). And other build systems/backends do (2).
The macro is documented as:
Specifically, the special linkage declarations should be
__attribute__ ((visibility ("default")))on GCC/clang, and__declspec(dllexport)on Windows.However, the definition assumes we're building CPython itself, and only adds a linkage declaration with
Py_ENABLE_SHARED-- that is, when Python itself is built with a shared library.According to MSVC docs:
Setuptools, and historically distutils, does (2) -- and so does, presumably, any other build system for native extensions on Windows.
However, this breaks for modules that define the PEP-793
PyModExporthook.It would be great to switch to the preferred (1), and then tell Setuptools to avoid
/EXPORTfor 3.15+.Linked PRs
__declspec(dllexport)on Windows #141672