嘿，我太懂你这种被GLIBC版本卡脖子的滋味了——嵌入式设备没法随便升级系统，交叉编译的工具链又偏偏自带了更高版本的依赖，简直头疼。结合你的情况，给你几个靠谱的解决思路：

核心问题根源 #

你遇到的问题本质是：Ubuntu上的交叉编译工具链使用的GLIBC版本（2.28）远高于树莓派CM3系统自带的2.24，导致编译出的程序在目标设备上找不到对应的库文件。手动升级GLIBC之所以失败，是因为它是系统的核心依赖库，直接替换会破坏系统稳定性，尤其是你的设备用了定制内核，兼容性风险更高。

可行解决方案 #

1. 使用与目标系统匹配的交叉编译工具链 #

这是最稳妥的方案，确保工具链的GLIBC版本和树莓派上的完全一致：

• 如果你用的是对应GLIBC 2.24的Raspbian Stretch系统，直接用树莓派官方提供的对应版本交叉编译工具链，或者从Stretch发行版的软件源里获取armhf架构的编译工具。
• 操作示例：下载官方Stretch版本工具链解压后，配置环境变量，用arm-linux-gnueabihf-gcc编译时，工具链会自动链接目标系统兼容的GLIBC版本。

2. 尝试在树莓派CM3本地编译 #

如果你的程序编译时间不长，直接把代码传到CM3上用系统自带的gcc编译，这样生成的二进制文件天生就和系统的GLIBC兼容。虽然嵌入式设备性能弱，但胜在绝对不会有版本匹配问题，适合小型项目。

3. 用Musl Libc替代GLIBC进行编译 #

如果静态链接是你能接受的选项（虽然GLIBC静态链接不推荐，但Musl天生适合静态编译）：

• Musl是一个轻量级的C标准库，静态编译出来的程序不依赖系统的GLIBC，能直接在目标设备上运行，而且稳定性有保障。
• 操作示例：安装musl的交叉编译工具链（比如arm-linux-musleabihf-gcc），编译时加上-static选项，生成的二进制文件就能在CM3上直接运行，不需要担心GLIBC版本问题。

为什么不推荐静态链接GLIBC？ #

你查到的“不推荐静态链接GLIBC”是对的，因为：

• 静态链接GLIBC会让程序体积变大，而且无法享受系统GLIBC的安全补丁更新。
• GLIBC的部分功能（比如线程、NSS名称服务）依赖动态链接，静态编译可能导致这些功能失效或出现兼容性问题。

备注：内容来源于stack exchange，提问作者anonymous