Windows: python.exe fails to start from a long path because of DLL manifests

未关闭
  • 哪里不对？
#160,624 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
28/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
python
领域
build-system

调研方向

Read PC/python_nt.rc and PC/sqlite3.rc, then inspect the executable resource scripts to compare how manifests are embedded. The proposed change removes the ID 2 manifest resource and its fallback define from the two DLL resource scripts; keep the executable manifests at ID 1. Done means DLLs no longer embed that manifest while the executables retain theirs, and long-path startup and extension imports work on Windows.

由索引模型根据 Issue 内容生成。

描述

build OS-windows type-bug
Bug report
Problem

python.exe fails to start with STATUS_NAME_TOO_LONG once its path is 247 characters or longer, even with LongPathsEnabled=1. It turns out this is actually from loading the DLL, not from python.exe itself.

Extension modules like _ctypes and _ssl also fail to import when the install is at a long path.

Cause

The build is creating DLLs with a manifest, and as noted in #126929, Windows can't load a DLL with an embedded manifest from a path near MAX_PATH.

Since about 2010, the manifest doesn't do anything in a DLL. Windows takes the supported OS versions and the Common Controls dependency from the EXE's manifest, not a DLL's.

History

DLLs used to need a manifest. With Visual C++ 2008, which Python 2.6 through 3.2 were built with, a DLL had to declare its dependency on the C runtime in an embedded manifest to find it. However, Visual C++ 2010 stopped using manifests to find the C runtime, so DLLs haven't needed one since.

#67207 (bpo-23018) added the manifest to python_nt.rc in 2015, at the same time as the one for python[w].exe, to declare supportedOS so that GetVersion would stop reporting Windows 8 on newer versions.

In 2016, #71496 (bpo-27309) added the Common Controls dependency so that tkinter's native dialogs would get the right styles. From that change: "Windows needs to load a different version of a particular DLL for the entire process." However, that's only information that the process needs, not the DLLs.

#71918 (bpo-27731) added longPathAware later that year.

Where the manifest comes from now

PC/python_nt.rc embeds PC/python.manifest as resource ID 2, and pythoncore, python3dll, and every extension module project in PCbuild use that resource script. PC/sqlite3.rc does the same for sqlite3.dll.

Possible Solution

Remove the 2 RT_MANIFEST "python.manifest" line, and the RT_MANIFEST fallback define above it, from PC/python_nt.rc and PC/sqlite3.rc. python_exe.rc and pythonw_exe.rc keep embedding the manifest as ID 1.

Note: #156759 doesn't help here, because Windows loads python3XY.dll as a static import of python.exe, before any Python code runs.

CPython versions tested on:

3.14

Operating systems tested on:

Windows

Linked PRs
  • gh-160626
主要语言
Python
星标
77.8k
派生
37.7k
平均合并
15 小时 24 分钟
30 天内合并 PR
728

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

python/cpython 的其他 Issue

查看 python/cpython 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。