1. 为何依赖列表中存在GLIBC_2.29和2.33，却没有GLIBC_2.31？ #

GLIBC的版本符号并非连续递增——只有当某个函数的ABI（应用二进制接口）发生变更时，才会新增对应的版本符号。你的二进制文件中引用的函数，在GLIBC 2.29之后，直到2.33版本才出现需要更新版本符号的ABI变化，中间的2.30、2.31、2.32版本没有修改这些函数的ABI，因此不会出现在依赖列表里。

举个例子：如果你的代码调用了某函数，该函数在GLIBC 2.29是GLIBC_2.29版本，直到2.33版本才做了ABI调整（比如参数结构变化、返回值类型修改），此时才会生成GLIBC_2.33的版本符号，中间版本的GLIBC对该函数的实现没有ABI变化，无需新增版本符号。

2. 被标注为“移除”的符号为何能在高版本GLIBC运行？ #

你提到的clock_gettime、pthread_attr_destroy、pthread_attr_init并没有被GLIBC真正移除，只是符号版本的归属发生了变化：

• 比如clock_gettime在GLIBC 2.26之前可能属于某个旧版本符号，之后被合并到更高的版本组中，但函数实体依然存在。
• Rust的标准库、tokio等依赖会通过弱符号绑定、符号别名或者编译时的兼容性处理，让代码调用自动映射到当前GLIBC中存在的有效符号版本。即使旧版本符号被标记为“废弃”，高版本GLIBC仍会保留兼容实现，保证旧代码可以正常运行。

另外需要注意：GLIBC的“移除”通常指旧版本符号不再被推荐使用，而非彻底删除函数实现——向后兼容是GLIBC的核心设计目标之一。

3. 为何低版本GLIBC编译的代码能在高版本运行，反之不行？ #

这是GLIBC的核心兼容性规则：向前兼容，不向后兼容：

• 低版本GLIBC编译的二进制，依赖的是低版本的符号，而高版本GLIBC会保留所有旧符号的兼容实现，因此可以正常运行。
• 高版本GLIBC编译的二进制，会依赖高版本新增的符号，低版本GLIBC中没有这些符号，因此启动时会报版本缺失错误。

修复建议 #

针对你的问题，可通过以下方式解决：

• 使用旧版本系统/容器编译：比如用Ubuntu 20.04（GLIBC 2.31）或CentOS 7（GLIBC 2.17）的Docker容器构建，确保编译环境的GLIBC版本低于目标运行环境的最低版本。
• 静态编译：在Rust编译时添加参数-C target-feature=+crt-static，将GLIBC静态链接到二进制中（注意：部分动态依赖可能无法静态链接，且静态编译的二进制体积会更大）。
• 切换到musl libc：使用musl作为C标准库（编译时指定--target x86_64-unknown-linux-musl），musl是静态链接的，不依赖系统GLIBC，可彻底解决版本兼容问题。
• 检查依赖特性：排查tokio或其他Rust依赖是否启用了需要高版本GLIBC的特性，尝试禁用不必要的特性以降低版本要求。

内容的提问来源于stack exchange，提问作者Jury