如何解决交叉编译时目标设备与构建机的GLIBC版本不匹配问题

你的问题核心是编译环境的GLIBC版本（2.16及以上）远高于目标设备搭载的GLIBC版本（2.13），交叉编译出的二进制依赖高版本GLIBC的符号，在低版本环境下无法运行，可选择以下任一方案解决：

• 方案1：静态编译（优先推荐，操作成本最低）
  编译时在链接参数中添加-static标识，将GLIBC等所有依赖库打包到最终的二进制文件中，不再依赖目标设备的系统库。
  示例修改：原编译命令为arm-linux-gnueabihf-gcc your_code.c -o fabs-uc8100 -lssl，修改为：

  arm-linux-gnueabihf-gcc -static your_code.c -o fabs-uc8100 -lssl -lcrypto
  

  注意：如果使用Makefile/CMake等构建工具，只需在链接参数全局配置中添加-static即可，无需修改业务代码。静态编译生成的二进制体积会比动态编译大，若设备存储空间充足，该方案最稳妥。
• 方案2：匹配编译环境与目标设备的GLIBC版本
  目标设备的GLIBC 2.13对应Debian 7（wheezy）版本，你可以安装Debian 7的虚拟机或Docker容器，在该环境下安装对应版本的arm-linux-gnueabihf交叉编译工具链，再编译你的程序，生成的二进制默认链接GLIBC 2.13版本符号，可直接在设备上运行。
• 方案3：强制绑定低版本GLIBC符号
  可在代码中添加GLIBC版本编译标记，强制编译器链接2.13版本的GLIBC符号，该方案操作复杂度高，若你的代码用到了2.13之后新增的GLIBC接口会直接编译失败，仅适合熟悉GLIBC机制的开发者使用。

注意事项 #

若选择静态编译方案，需确保你依赖的第三方库（如libssl-dev:armhf）已安装对应的静态版本（后缀为.a的库文件），如果缺失可自行下载对应版本的源码静态编译后再链接。

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