FrankenPHP二进制与CentOS Stream 9的glibc-2.34不兼容，因其可能为Ubuntu/Debian或更高glibc环境构建；应优先选用标有centos-stream-9、rhel-9或manylinux2014的官方预编译包，或源码编译、容器运行。
CentOS Stream 9 自带 glibc-2.34，FrankenPHP 官方二进制却报 GLIBC_2.34 not found ——这基本不是系统版本问题，而是你下载的 FrankenPHP 二进制压根不是为 Stream 9 编译的，极大概率是 Ubuntu/Debian 环境下用 glibc-2.35+ 或 musl 打包的。
怎么确认真是 glibc 版本冲突，而不是别的问题
别急着升级或打补丁，先做三件事：
- 运行
ldd --version，确认输出是ldd (GNU libc) 2.34（Stream 9 默认值，不是 2.17 或 2.28） - 用
file frankenphp检查二进制类型，如果显示ELF 64-bit LSB pie executable且带for GNU/Linux 4.15.0这类字样，说明它可能是在较新内核+高 glibc 环境构建的 - 执行
readelf -d frankenphp | grep NEEDED，重点看有没有libc.so.6行；再加| grep VERSION，若出现GLIBC_2.35或更高，就坐实了版本声明超标
为什么 patchelf 在 Stream 9 上大概率失效
Stream 9 的 patchelf（通常来自 EPEL）默认是 0.14.x，而修改 glibc 符号版本需要 >= 0.18。更关键的是：glibc 自 2.34 起引入了 symbol versioning 的严格校验机制，单纯用 --replace-needed libc.so.6 libc.so.6 不再能绕过 GLIBC_2.35 这类声明——链接器会在加载时直接拒绝。
你可能会看到新报错：/lib64/ld-linux-x86-64.so.2: symbol _dl_exception_create, version GLIBC_PRIVATE not defined，这就是 patchelf 强行降级后触发的内部符号断裂。
立即学习“PHP免费学习笔记（深入）”；
真正可行的三条路，按推荐顺序
别碰系统 glibc 升级——Stream 9 的 2.34 已是当前稳定上限，强行装 2.35+ 会破坏整个 DNF/YUM 生态，包括 kernel module 加载和 systemd 启动。
-
换构建来源：去 FrankenPHP GitHub Releases 页面，找标有
centos-stream-9、rhel-9或manylinux2014的资产（asset），这类二进制明确声明兼容 glibc-2.34；manylinux2014 是 Python 社区定义的最低兼容标准，对应 glibc-2.17，反而在 Stream 9 上一定跑得通 -
源码编译：克隆官方仓库，在 Stream 9 机器上运行
make build（需提前装gcc-toolset-12、openssl-devel、libcurl-devel）；这样生成的二进制只会声明系统实际提供的符号版本，零风险 -
容器隔离：用
podman run --rm -it -v $(pwd):/app docker.io/frankenphp/frankenphp:latest /app/frankenphp，完全避开宿主机 glibc，适合快速验证或 CI 场景
最常被忽略的一点：FrankenPHP 的某些预编译包其实内嵌了 PHP 运行时，而 PHP 自身又依赖 OpenSSL、cURL 等库——这些库的 glibc 版本声明可能比主程序还高。所以光修 frankenphp 二进制没用，得连同它依赖的 libphp.so 一起处理。这也是为什么直接 patchelf 常常修了又崩。
