Repository navigation
Conversation
…n Windows The stable ABI forwarder DLLs are linked with /NOENTRY, so nothing pulls in the CRT. With AddressSanitizer enabled, the linker adds the ASan runtime thunk library, which needs the CRT, and the link fails with unresolved symbols. Keep the default CRT entry point for these DLLs when building with ASan.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Thank you for your interest in contributing to Python. This is a community-driven project, and we want it to be a welcoming place to learn and collaborate. Contributors are responsible for reviewing and understanding what they submit, checking its claims, and being able to explain changes in their own words. This helps reviewers focus on the contribution and leaves more time to support other contributors. This contribution appears to have been authored with AI assistance. Please explain your contribution in your own words and describe how you checked its correctness. Please read our guidelines for using AI tools. |
|
LGTM, but see my earlier #150467 (comment) before we proceed here. |
|
Agreed, made some changes regarding the comment you linked. Thanks. |
Fixes gh-150467.
Root cause
python3.dll and python3t.dll only contain
/EXPORTforwarders and are linked with/NOENTRY, so the CRT is never pulled in. With ASan enabled, the linker addsclang_rt.asan_dynamic_runtime_thunk, which needs the CRT (_initterm,abort,__vcrt_*,__acrt_*), so the link fails with LNK2001.python3.dll fails the same way before GH-149218. That change made the problem visible by adding a second forwarder that always gets built.
Fix
pyproject.propssetsPyUsingAsanwhen ASan is enabled throughEnableASAN=true,/fsanitize=addressin_CL_, or/InferASanLibsin_LINK_.python3dll.vcxprojandpython3tdll.vcxprojonly setNoEntryPointwhenPyUsingAsanisn't set, so ASan builds use the default CRT entry point.Non-ASan builds are unchanged: both DLLs still have no entry point and no imports.
Testing
x64 Release, VS 2026 (MSVC 14.51), ASan enabled with the
_CL_/_LINK_settings from the issue:build.bat -e --no-tkinter -p x64 -M -r: failed before, links now.--disable-gil: failed before, links now.dumpbinshows the forwarders unchanged.test_syspasses on all four builds, andtest_capipasses on the free-threaded builds.