基于Linux RT（Arm Cortex A8）的研华ADAM 5630 PLC程序编译报错咨询：libstdc++.so.6缺失CXXABI_1.3.8版本

你遇到的问题确实是交叉工具链和目标PLC系统的C标准库版本不兼容导致的——你的交叉编译器（arm-linux-gnueabihf-g）依赖的libstdc版本更高（CXXABI_1.3.8是GCC 5.1及以上版本引入的新ABI规范），而PLC上的libstdc.so.6.0.17只支持到CXXABI_1.3.7（对应GCC 4.9.x系列）。小测试程序能正常运行，是因为它没有用到触发新ABI的C++特性，复杂程序调用了这些特性就触发了版本错误。

下面给你几个可行的解决办法，你可以根据自己的需求选择：

方案1：静态链接libstdc++库（快速验证首选） #

这是最直接的临时解决方案，把程序依赖的libstdc++代码直接编译进可执行文件，不再依赖PLC上的动态库。编译时只需添加-static-libstdc++参数即可：

arm-linux-gnueabihf-g++ your_program.cpp -o your_program -static-libstdc++

注意事项： #

• 这个方法会增大可执行文件的体积，但能快速绕开版本不兼容问题，适合快速验证程序功能。
• 如果你的程序还依赖研华提供的其他动态库，只要这些库不依赖高版本的libstdc++，这个方法就能正常工作。

方案2：降级工具链到匹配PLC的GCC版本（长期稳定首选） #

PLC上的libstdc++.so.6.0.17对应GCC 4.9.x系列（你可以在PLC上执行strings /lib/libstdc++.so.6 | grep CXXABI确认它支持的ABI版本列表），你需要匹配这个版本的交叉工具链：

• 优先尝试找研华官方提供的、与PLC系统版本配套的SDK：因为PLC的系统是用Yocto构建的，配套的SDK会和目标系统的库版本完全对齐，从根源避免版本问题。
• 如果研华没有提供，你可以手动下载GCC 4.9.x版本的arm-linux-gnueabihf交叉编译器（比如Linaro的旧版本工具链），用这个旧版本的编译器编译你的程序。

方案3：替换PLC上的libstdc++.so.6库（风险较高，谨慎操作） #

如果PLC允许你修改系统文件（部分工业设备的文件系统是只读的，需要先执行mount -o remount,rw /挂载为可写），你可以尝试把工具链对应的libstdc++库复制到PLC上，更新软链接：

1. 在VirtualBox的工具链sysroots中找到arm架构的libstdc++.so.6.0.25，路径大概是：

   /opt/ti-processor-sdk-linux-rt-am335x-evm-04.03.00.05/linux-devkit/sysroots/armv7ahf-neon-linux-gnueabi/usr/lib/libstdc++.so.6.0.25
   

2. 通过scp把文件复制到PLC的/lib目录：

   scp libstdc++.so.6.0.25 root@<你的PLC IP地址>:/lib/
   

3. 在PLC上备份旧软链接并创建新的：

   cd /lib
   mv libstdc++.so.6 libstdc++.so.6.old
   ln -s libstdc++.so.6.0.25 libstdc++.so.6
   

风险提示： #

这个操作可能会导致PLC上其他依赖旧libstdc++的系统程序崩溃，操作前一定要备份原文件，并且在测试环境中先验证，不要直接在生产设备上操作。

方案4：使用Yocto构建配套SDK（工业级标准方案） #

研华的PLC系统是基于Yocto项目构建的，这是嵌入式Linux开发的标准流程。如果你打算长期开发这个PLC的程序，推荐学习基础的Yocto使用，获取研华ADAM 5630对应的Yocto BSP，然后构建与目标系统完全配套的交叉编译SDK。

这个方法门槛较高，但能从根源解决所有库版本兼容问题，也是工业嵌入式开发的规范做法。

内容来源于stack exchange