gcc升级后cc1找不到导致Python编译失败，根本原因是新gcc按相对路径查找cc1等组件，若仅硬链接gcc命令而未确保完整工具链路径可达，则configure或make时会报“cannot execute 'cc1'”；必须将PATH指向gcc安装目录的bin子目录，并同步设置LD_LIBRARY_PATH和LIBRARY_PATH以保障库依赖完整。
gcc 升级后 cc1 找不到，Python 编译直接失败
不是 Python 本身出问题，而是新版本 gcc 的执行逻辑变了：它默认按相对路径找 cc1、as、ld 等配套组件。如果你只是把 /opt/gcc-13.2.0/bin/gcc 复制或硬链接到 /usr/bin/gcc，那它运行时仍会去原目录（比如 /opt/gcc-13.2.0/libexec/gcc/x86_64-pc-linux-gnu/13.2.0/cc1）找 cc1，而这个路径在 /usr/bin 下根本不存在。
现象就是 configure 阶段报错：configure: error: C compiler cannot create executables，或者编译 Python 源码时卡在 make，提示 fatal error: cannot execute 'cc1': execvp: No such file or directory。
- 别用
cp /opt/.../gcc /usr/bin/gcc这种“偷懒”方式替换系统编译器 - 必须让
PATH指向完整安装目录的bin/子目录，确保所有配套工具都在可发现路径下 - 验证是否生效：运行
gcc -print-prog-name=cc1，输出应为绝对路径且文件真实存在
Python ./configure 依赖 gcc 的运行时行为，不只看命令是否存在
Python 源码编译时的 ./configure 脚本会实际调用 gcc --version、gcc -dumpmachine，甚至尝试编译一个最小测试程序（conftest.c）。哪怕 gcc 命令能执行，只要它在后台调用 cc1 失败，整个 configure 就判定编译器不可用。
这和单纯装个 build-essential 或 gcc 包不同——那些包自带完整工具链布局；而手动升级的高版本 gcc 往往是解压即用型，路径结构更“干净”，也更脆弱。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
-
./configure不检查cc1是否存在，只信 gcc 的返回值；失败时错误信息非常笼统，容易误判为权限或磁盘问题 - 若你用 pyenv、asdf 等版本管理器，它们内部调用
configure时同样受此影响，报错位置可能藏在 build log 深处 - 临时修复可加
--without-ensurepip跳过 pip 编译环节，但治标不治本
Linux 上混用多个 gcc 版本时，LD_LIBRARY_PATH 和 LIBRARY_PATH 也得同步更新
新版 gcc 常依赖新版 glibc 或自建的 libgcc、libstdc++。如果只改了 PATH，没同步设置库路径，Python 编译出的二进制（比如 _ssl、_hashlib 模块）在运行时可能因找不到符号而崩溃，错误表现为 ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found。
- 除了
export PATH="/opt/gcc-13.2.0/bin:$PATH"，还需补上：export LD_LIBRARY_PATH="/opt/gcc-13.2.0/lib64:$LD_LIBRARY_PATH" -
LIBRARY_PATH（用于编译期链接）也建议设上：export LIBRARY_PATH="/opt/gcc-13.2.0/lib64:$LIBRARY_PATH" - 这些变量必须在
./configure和make之前就生效，不能只在 install 后设置
为什么 Tkinter、zlib、SSL 这些模块常跟着一起挂？
它们不是独立故障，而是 gcc 编译器链断裂的连带结果。Python 的 Modules/Setup 文件里，_tkinter、zlib、_ssl 等模块都依赖外部系统库（tcl8.6、zlib、openssl），而检测这些库是否可用的逻辑，全靠 gcc 调用 pkg-config 或直接尝试编译链接测试代码完成。
一旦 gcc 本身失能，所有依赖编译探测的模块都会被静默跳过，最终 Python 安装完却缺一堆标准库功能，报错如 zipimport.ZipImportError: can't decompress data; zlib not available 或 ModuleNotFoundError: No module named '_tkinter'。
- 不要单独重装
zlib-devel或tcl-devel来试图修复——根源不在它们，而在 gcc 无法完成探测 - 验证 gcc 是否真正可用：写一个空
main.c，执行gcc -o main main.c && ./main，成功才是硬指标 - 最省事的兜底方案：退回系统自带 gcc（如 CentOS 7 的 4.8.5），用它编译 Python，再用新 gcc 编译业务 C 扩展，二者分离开
