ROS2这个圈子有个经典定律拿到一块新板子第一件事永远是编译环境折腾得你想砸电脑。RK3576这块芯片本身性能不差在一些国产边缘计算板卡和机器人主控上用得越来越多但它的软件生态相比树莓派或者Jetson还是要折腾不少。我自己在给RK3576开发板交叉编译ROS2 Humble的时候第一眼看到的就是一长串GLIBCXX版本缺失报错那一刻血压直接拉满。这篇文章就是把我从零开始折腾的过程、踩过的坑、以及最后稳定复现的一套交叉编译流程完整拆给你希望能帮你少走至少两天的弯路。文章会覆盖几个大部分人都躲不过的问题为什么RK3576上直接编译ROS2会卡在GLIBCXX、交叉工具链到底该怎么选怎么配、sysroot到底是个什么东西、以及ROS2源码编译时常见的依赖和CMake坑。不管是刚开始接触嵌入式Linux的小白还是被树莓派惯坏的老手这套流程应该都能直接照抄作业。1. 先搞清楚RK3576的软件底座再动手1.1 RK3576能在板子上“本地编译”ROS2吗先说结论能但非常不推荐。RK3576虽然是一颗8核的处理器核心是4个A72加上4个A53主频最高能到2.2GHz左右听着好像还不错但和你的电脑比还是有代差。我在板子上试过直接跑colcon build一个最基础的talker/listener功能包就要编译好几分钟如果是要编rviz2、nav2这种重量级功能包一个包就能磨蹭半个小时以上整机编下来一整天都不一定搞得定。更麻烦的是在板子上做所谓“本地编译”等于你在用非常有限的内存和CPU资源干重体力活开发板的存储通常也比较吃紧编译中间文件动不动就占好几个G很容易把空间撑爆。所以如果只是调试现有的功能包本地编译还能凑合但如果你要把整个ROS2基础平台、中间件、甚至工具链一起装好交叉编译几乎是唯一理智的选择。所谓交叉编译就是在一台性能比较强的宿主机上生成目标平台架构的二进制然后把编译产物拷贝到开发板上运行。RK3576是ARM架构宿主机通常是一台x86_64的Ubuntu机器两边架构不同你直接在用gcc编出来的东西在板子上是跑不起来的必须用专门针对ARM的交叉编译工具链来干活。这个过程在逻辑上和你给安卓手机开发App很像。你在电脑上写Java或者Kotlin代码最终生成的APK是运行在手机上ARM芯片上的靠的就是Android SDK里自带的那套交叉编译工具链。ROS2交叉编译本质上也是这么个思路只是把工具链换成了GCC系的交叉编译版本而已。1.2 宿主机环境准备别在Windows上硬刚交叉编译的第一步是有一个干净的Ubuntu环境。我自己用的是Ubuntu 22.04这个版本也是ROS2 Humble官方推荐的系统版本之一。如果你只有Windows建议直接装一个VMware或者VirtualBox虚拟机分配至少8GB内存和100GB硬盘空间编译过程资源吃紧会非常痛苦。这里有个很重要的细节宿主机Ubuntu的版本基本决定了你能用哪一版的GCC交叉工具链而工具链的版本又直接和你后面会遇到的GLIBCXX问题挂钩。Ubuntu 22.04自带的是GCC 11Ubuntu 20.04自带的是GCC 9两个版本对于C标准库的实现有差异。ROS2 Humble官方要求的是GCC 11所以如果你拿20.04当宿主机后面编译ROS2很容易遇到标准库版本不够的情况报错就是你要找的GLIBCXX_3.4.28 not found这类。为了从一开始就不给自己挖坑我建议直接上22.04。另外无论你用虚拟机还是物理机都要保证磁盘空间充足。交叉编译ROS2 Humble我实测下来至少需要40GB到60GB的可用空间其中ROS2源码加上下载的依赖包大概要占10GB左右编译生成的中间目录build/和安装目录install/又会占掉不少。如果你的磁盘只有20GB那编到一半被“No space left on device”打断是必然的。提示如果你之前已经在自己电脑上装过ROS2并且是用apt方式安装的那建议先把系统里的ROS2环境变量隔离干净避免交叉编译时CMake认错了依赖。最稳妥的办法是建一个全新的Ubuntu虚拟机专门做交叉编译。2. 交叉工具链选型和sysroot的底层原理2.1 工具链选型用Linaro还是用厂商SDK自带这是很多人第一个卡住的地方。当前ARM交叉编译工具链有几种选择最常用的是Linaro提供的aarch64-linux-gnu-系列这套工具链就是GCC的ARM版本用法非常标准。另一个选择是用你手上开发板厂商SDK里自带的工具链比如Rockchip官方SDK里通常会带着一套aarch64-rockchip-linux-gnu开头的交叉编译器这套一般是用Buildroot定制过的编译出来对自家芯片的优化更好。我的建议是如果没有特殊原因直接用gcc-aarch64-linux-gnu这套也就是Linaro工具链在Ubuntu上用一条命令就能装好sudo apt update sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu装完之后用aarch64-linux-gnu-g --version验证一下如果能正常输出版本号说明工具链工作正常。选择这套工具链的理由有三个第一它是Ubuntu官方源里维护的版本和系统自带的GCC对齐不会出现你宿主机用GCC 11编出来的目标文件结果交叉编译器是GCC 9的版本两边标准库接口对不上的坑。第二Linaro工具链对ARMv8-A架构的支持非常完善而RK3576正好是ARMv8.2-A的Cortex-A72加A53大小核架构指令集兼容没有任何问题。第三社区生态最成熟你遇到问题时网上能搜到大量相同的解决方案。如果你是做产品的需要深度的厂商支持那用Rockchip SDK自带工具链也没问题。但从纯技术门槛角度讲Linaro工具链会让你少踩很多版本配对的坑。2.2 sysroot到底是什么为什么要用它很多人一看到“sysroot”这个词就头疼但它的逻辑其实特别简单。你的目标板系统里有一个根文件系统里面放着各种动态库、头文件、配置文件路径是/usr/lib、/usr/include这些。交叉编译的时候你需要在宿主机上模拟出目标板的完整根目录结构让编译器在编译时能搜到目标板系统里的头文件和动态库这个被模拟出来的根目录就叫sysroot。打个比方你在电脑上写程序时编译器会自动去/usr/include里找标准库的头文件去/usr/lib里找标准库的二进制文件。但是在交叉编译时目标板上运行的操作系统和你电脑上的操作系统不是同一个你不能直接拿电脑上的头文件和库文件去给板子上的程序用。所以你需要先把板子上的整个根文件系统复制到宿主机上的某个目录下比如~/rk3576-sysroot然后告诉交叉编译器“你需要的所有系统文件都去这个目录里找”这就是sysroot的用途。这里就引出了交叉编译ROS2时的一个关键操作你需要一个和开发板上完全一致的sysroot。最直接的办法是准备一张刷好操作系统的TF卡或者连上开发板的调试串口把板子上的/usr、/lib、/lib64这些关键目录打包拷贝到宿主机上。很多人图省事只拷贝了/usr/include和/usr/lib结果编译时老提示找不到各种奇怪的头文件就是因为sysroot不完整。我自己用的流程是# 在开发板上执行 sudo tar -cvzf sysroot.tar.gz --exclude/proc --exclude/sys --exclude/dev --exclude/run /usr /lib /lib64 /etc然后把这个tar包拷贝到宿主机上解压到指定目录比如~/rk3576-sysroot之后交叉编译时统一用--sysroot~/rk3576-sysroot参数指定。当然这种做法覆盖了大部分情况但如果板子上的库被你后续更新过sysroot也需要跟着更新否则编译出来的程序在板子上运行动态库对不上版本依然会崩溃。2.3 一份能直接用的CMake交叉编译配置文件ROS2是用CMake作为构建系统的所以交叉编译的核心就是写一个CMake toolchain文件让CMake在配置阶段知道要用的编译器、sysroot路径、目标架构这些信息。下面是我整理的一份能直接用的配置文件保存成rk3576_toolchain.cmakeset(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_SYSROOT $ENV{HOME}/rk3576-sysroot) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH $ENV{HOME}/rk3576-sysroot) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) set(CMAKE_CROSSCOMPILING TRUE)这里面最关键的是CMAKE_FIND_ROOT_PATH_MODE_*这三行。它们的含义是程序文件在宿主机上找但库文件、头文件、CMake包配置只能在sysroot里找。如果不设置这些CMake会去你宿主机的/usr/lib里找库这样找到的是x86_64的库链接的时候会直接报架构不匹配的错误。另一个需要注意的点是CMAKE_SYSROOT和CMAKE_FIND_ROOT_PATH要同时设置两者之间有一点微妙差异。CMAKE_SYSROOT主要是给编译器的--sysroot参数用让编译器在sysroot目录里查找头文件和系统库。CMAKE_FIND_ROOT_PATH是给CMake的find_package和find_library机制用让CMake在指定目录下查找第三方库。两者配合使用才能让整个查找链路都指向目标板的根文件系统。注意如果你的sysroot目录不是放在$HOME下记得把配置文件里的路径改成实际路径。还有用环境变量来指定路径是个好习惯这样不同人拉下来代码后不用改线修改toolchain文件。3. ROS2源码编译的完整流程实战3.1 为什么交叉编译必须走源码编译不能走aptROS2官方推荐的安装方式是用apt直接安装二进制包这种方式在PC上非常爽一条命令搞定一切。但在开发板上用apt装ROS2通常会遇到两个问题一是ROS2官方源并不总是提供arm64的二进制包特别是你如果用的不是Ubuntu LTS版本或者架构比较特殊的话源里根本没有对应包二是即使源里有包版本也比较旧而且你很难对这个ROS2做深度定制。所以交叉编译场景下源码编译几乎是一定的。源码编译的本质是你把ROS2的各个功能包源码拉下来在宿主机上用交叉编译工具链把它们编译成arm64的二进制然后把编译好的安装目录部署到开发板上配置好环境变量就能用了。这个过程类似安卓开发里的“打一个APK包装到手机上”只是ROS2的“APK包”是一整个文件树。ROS2 Humble版本对应的发行架构是humble分支你可以用repo工具或vcstool把官方定义的各个仓库源码一次性拉下来。为了节省时间我强烈建议用vcstool配合ros2的ros2.repos文件来拉取源码这个文件里定义了ROS2核心功能包的所有git仓库地址和分支。拉取命令如下mkdir -p ~/ros2_humble_ws/src cd ~/ros2_humble_ws wget https://raw.githubusercontent.com/ros2/ros2/humble/ros2.repos vcs import src ros2.repos所有源码拉到本地后需要先检查一下各个仓库的分支是不是都切到了正确的humble分支。有时候因为网络问题某些仓库可能没拉全会导致后续编译报错。检测命令是vcs status如果发现有仓库没拉干净用vcs pull重新拉一下。3.2 colcon build交叉编译的完整命令和参数ROS2的构建工具是colcon它会在你指定的工作空间里扫描各个功能包然后逐个编译并安装到install/目录。交叉编译时要让colcon走CMake toolchain文件需要用--cmake-args参数传递额外的CMake定义cd ~/ros2_humble_ws colcon build --cmake-args \ -DCMAKE_TOOLCHAIN_FILE/path/to/rk3576_toolchain.cmake \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_SYSROOT$HOME/rk3576-sysroot这段命令里-DCMAKE_TOOLCHAIN_FILE指定了交叉编译配置文件-DCMAKE_BUILD_TYPERelease表示编译Release版本去掉调试符号和优化会更好。这里要提醒一点ROS2编译时不要轻易加-j参数去并发编译除非你宿主机的内存特别大。我自己实测内存16GB的机器开-j8编译内存占用会飙到10GB以上如果内存小编译器内存不够会直接OOM崩溃这种错误很难排查因为它不一定发生在同一段时间而是随机的。还有一个容易翻车的点ROS2的很多功能包在编译时会调用Python的一些本地库这些库也需要交叉编译。如果你在宿主机上直接用系统Python的pip装依赖那装的还是x86_64的包后面ROS2编译时会报一些Python模块找不到或者架构不对的错误。所以交叉编译ROS2前你必须用--python-tag参数来告诉colconPython的依赖库也要从目标板的架构出发去交叉安装。具体操作方法是给pip加--platform和--target参数把依赖装到sysroot对应的Python路径下。这部分官网文档写得不详细但实际踩坑的人非常多。3.3 编译中必然会遇到的三类经典报错交叉编译ROS2时报错是常态不报错才奇怪。我自己编译Humble时候遇到最多的有三类问题这里提前帮你排雷。第一类是CMake找不到依赖包典型报错是Could not find a package configuration file provided by XXX。这种问题八成是sysroot不完整目标板上某个ROS2和系统库依赖的头文件缺失了。解决办法是先确认sysroot里有没有对应的.cmake文件如果没有回到开发板上把缺失的那部分库打包补进sysroot。第二类是链接阶段报错典型表现是undefined reference to xxx或者cannot find -lxxx。这类问题一般是链接器在sysroot里找不到对应的动态库文件要么是那个库没被打包进sysroot要么是版本和编译时依赖的不一致。我的排查思路是先看报错里缺的库文件名字再去sysroot里用find命令搜一下基本都能定位到问题。第三类是Python相关的问题比如No module named em、No module named catkin_pkg等。这是因为ROS2的构建脚本本身就是用Python写的它需要很多Python包来辅助构建。这个问题相对好解你用系统自带的pip3把empy、catkin_pkg、lark这些包装上就行。但注意安装时不要用--user参数否则装到当前用户的家目录下构建时又找不到。4. GLIBCXX缺失的终极排查与解决4.1 GLIBCXX版本号到底代表了什么GLIBCXX是一个贯穿整个章节的核心概念。很多人看到GLIBCXX_3.4.30 not found这类报错就懵了其实它和GLIBCGNU C Library是两回事。GLIBC是C标准库文件名是libc.so.6GLIBCXX是C标准库也就是libstdc的一部分文件名是libstdc.so.6。每次GCC版本更新都会在libstdc.so.6里增加新的符号用版本号来标记比如GLIBCXX_3.4.30表示这个符号通常是某些C标准库的新增接口从GCC 12开始才引入。你交叉编译的程序在板子上运行时报这个错意思就是程序在编译好的时候引用了一个较新版本C标准库才有的符号但开发板系统里的libstdc.so.6太老了没有这个符号。常见的错误就是ROS2的程序在板子上跑或者连板子上的某个可执行文件都弹出一串GLIBCXX_3.4.x not found。用一行命令可以查看开发板上libstdc.so.6里到底支持到哪个版本的GLIBCXX符号strings /usr/lib/aarch64-linux-gnu/libstdc.so.6 | grep GLIBCXX输出的列表里会有一堆GLIBCXX_3.4.x它们是从老到新排列的。如果你在列表里找不到编译时报的那个版本号就说明你的C标准库版本不够新这就是报错的根源。4.2 这个问题出现在宿主机还是目标板判断方法GLIBCXX缺失有两种常见场景判断错场合会让解决办法完全跑偏。第一种场景是x86_64宿主机上编译时报错。你可能会想我就是在自己电脑上编译为什么还会报GLIBCXX缺失这种情况往往不是标准库缺失而是你宿主机上编译ROS2时调用了某个预编译的二进制库这个库是用比宿主机GCC更新版本的GCC编译的导致系统默认的libstdc.so.6不满足需求。解决办法是升级宿主机GCC版本或者找到那个会导致问题的第三方库换旧版本。第二种场景是编译完成后把程序拷贝到RK3576开发板上运行时报错。这种情况就是开发板上的libstdc.so.6版本不够新。RK3576开发板通常刷的Ubuntu版本比PC上的要老一些板子的系统镜像里自带的标准库版本跟不上编译用的GCC版本交叉编译时GCC 12编出来的程序带到板上跑板子上只有GCC 9的标准库就会报一堆GLIBCXX版本缺失。我自己最初的报错就是第二种./talker: /lib/aarch64-linux-gnu/libstdc.so.6: version GLIBCXX_3.4.30 not found (required by ./talker)看到这个报错第一反应不要慌先按顺序做两件事。第一步在开发板上执行strings命令看当前板的GLIBCXX支持到哪个版本号。第二步如果板子上版本确实不够那就是要把板子系统里的GCC标准库升级本质上是给开发板安装更高版本的GCC运行时库。注意这一步不是要升级整个GCC而是要把宿主机上交叉工具链里的新版libstdc.so.6拷贝到板子系统的/usr/lib/aarch64-linux-gnu/目录下覆盖掉旧版本。4.3 升级开发板libstdc的完整操作步骤这一步很多教程说得模糊我这里给一个完整的、我自己验证过的做法。前提是你已经交叉编译了ROS2且宿主机的交叉工具链版本是比较新的GCC比如GCC 12那么宿主机上会有一个对应的libstdc.so.6它的GLIBCXX支持最高版本往往是GCC 12对应的3.4.30之类。如果你的工具链是GCC 11Ubuntu 22.04默认那就是3.4.29。操作分三步第一步在宿主机上找到交叉工具链的libstdc.so.6文件路径find /usr -name libstdc.so.6 -path *aarch64*第二步拷贝这个文件到开发板的/usr/lib/aarch64-linux-gnu/目录下。这一步建议通过SSH或scp完成scp /usr/aarch64-linux-gnu/lib/libstdc.so.6.0.30 root板的IP:/usr/lib/aarch64-linux-gnu/第三步在开发板上把旧的软链接替换成新的cd /usr/lib/aarch64-linux-gnu/ sudo mv libstdc.so.6 libstdc.so.6.old sudo ln -s libstdc.so.6.0.30 libstdc.so.6 sudo ldconfig这里的核心原理是libstdc.so.6是一个软链接实际的文件是libstdc.so.6.0.xx。你用新版文件替换软链接系统里的库路径就指向了新版本。然后执行ldconfig刷新动态链接器的缓存整个板子的动态链接器就会优先使用新拷贝的库。仔细检查一下程序再跑一次GLIBCXX缺失的报错应该就消失了。注意覆盖系统库有风险操作前建议先备份。最保险的方式是先把系统原来的libstdc.so.6.0.x保留好万一新库有什么问题还能回滚。另外如果你同时也在板子上用apt装了一些依赖当这些依赖依赖旧库时替换版本可能引入新的动态库问题但实测对ROS2 Humble整体影响不大。4.4 如果是宿主机缺GLIBCXX直接升级GCC而不是乱装库还有一种情况需要区分出来你在宿主机上编译时CMake报了一个和你系统GCC版本不匹配的GLIBCXX错误比如你在Ubuntu 20.04上编译ROS2 Humble而ROS2 Humble需要GCC 11但系统默认还是GCC 9这个时候最高效的做法是升级宿主机GCC版本而不是去系统里改库文件。Ubuntu上可以用ubuntu-toolchain-r/test这个PPA源来安装更新版本的GCCsudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt update sudo apt install gcc-11 g-11 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 110 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-11 110装好之后用gcc --version确认默认的gcc已经切换到11版本再重新编译ROS2。通常这种情况下之前明明已经把交叉工具链版本配对得很好却还是冒出GLIBCXX版本缺失基本就是因为宿主机的gcc和系统库版本错位。5. ROS2交叉编译的部署与运行调试5.1 把编译好的install目录完整同步到开发板交叉编译成功后ROS2的产物主要在install/目录下。但这里有个坑很多人直接把install/目录拷贝到板子上就以为大功告成结果运行ros2命令时报各种找不到库的错误。原因在于install/目录下很多功能包是通过软链接指向src/或build/目录下的内容的直接拷贝软链接会失效。最稳妥的同步方式是用rsync的-L参数把软链接解析成实际文件再拷贝命令大致如下rsync -avL ~/ros2_humble_ws/install/ root板的IP:/opt/ros2_humble/如果你的板子和宿主机在同一局域网内比起用U盘拷贝直接用rsync通过SSH同步要方便得多。同步完成后在开发板上设置一下环境变量source /opt/ros2_humble/setup.bash在运行任何ROS2节点前先执行一下ros2 --help测试环境是否正常。如果提示command not found大概率是环境变量没设置或者install/目录结构没有正确同步过去。你可以用ls /opt/ros2_humble/看看bin目录下有没有ros2这个可执行文件。注意ROS2的消息包和服务包是基于DDS通信的如果你编译时的DDS实现和板子上运行时使用的DDS实现不一致也会出现节点间通信不上的问题。RK3576上比较常用的DDS是Fast DDS和Cyclone DDS交叉编译时默认会编Fast DDS如果你后续要换DDS一定要重新编译ROS2中对应的rmw层。5.2 运行时的权限和设备节点问题交叉编译好的ROS2镜像部署到开发板后运行ros2命令时报权限问题的概率也不小。特别是当你通过非root用户SSH登录开发板时经常会出现Permission denied或者操作某些设备节点失败。解决思路是把当前用户加入到dialout组串口设备需要的权限和sudo组同时把REPL和DDS相关的设备节点权限配置好。这里特别要提一个我在RK3576上遇到的细节运行ROS2节点时如果板子上同时跑着一些占用CPU密集型任务节点启动会非常慢甚至有一段时间看起来像卡死了其实是CPU在等资源。优化方式是给CPU设置更合理的调度策略或者在板子上关掉一些不必要的服务释放CPU资源。另外还要注意开发板的时间同步问题。ROS2的DDS通信对时间戳比较敏感如果板子和宿主机时间差太大节点会发现消息的timeout甚至无法正常发现彼此。交叉编译后的节点在调试时如果遇到“节点A能启动但发现不了节点B”的情况第一件事先检查和宿主机的时间是否一致直接执行date命令对比一下如果差太多用NTP同步一下时间再试。5.3 交叉编译后的ROS2还能不能用rosdep和apt装其他包这是个高频问题。你交叉编译生成了ROS2的一部分基础包后面想加一个社区里现成的功能包这时候你还想不想再重新走一遍完整的交叉编译流程合理的方法肯定不是的。两种方式可以供你参考。一种方法是把要添加的功能包源码拉进交叉编译工作空间重新执行一次colcon build --cmake-args ...只编译新加的功能包并安装到install目录。这个过程和你第一次编译相同只是时间短很多因为ROS2核心包都已经编过了增量编译就行。但要注意新增功能包如果依赖你之前没编过的ROS2基础包那这个基础包也会被触发重新编译时间不一定短。另一种方法是如果你需要用apt安装功能包及其依赖就只能在开发板上用arm64的deb包来装。这种做法需要你的开发板源里有对应arm64包且版本要和编译的ROS2版本匹配。比如要装ros-humble-nav2就要在板子上先配置好ROS2的apt源然后执行sudo apt update sudo apt install ros-humble-nav2这种方式装出来的包是板子原生arm64的不会和你交叉编译的ROS2冲突前提是版本一致。我的习惯是核心平台用交叉编译来保证一致性周边工具用apt在板子上补齐这种混搭策略在实际项目中非常有效率。6. 这个流程我能给你的最后一个优化建议整套交叉编译流程走通之后我的体会是RK3576上交叉编译ROS2难点其实不在ROS2本身而在环境的一致性和版本的匹配上。GLIBCXX问题说到底就是一条动态库版本链的问题交叉工具链选型、sysroot的完整性、CMake配置文件的正确性这些工作做好了后面的编译过程其实就是一个等待时间的问题。如果你现在正好卡在某个报错上我建议你按这个顺序排查一遍先确认宿主机GCC版本和交叉工具链版本是否配对再检查sysroot是否完整接着看CMake toolchain文件的路径是否有错最后如果是在板子上运行报错重点查板子上的libstdc.so.6版本。这四步走完至少能解决八成以上的问题。最后再分享一个小技巧在你彻底搞定一套可用的sysroot和toolchain文件之后建议把这两个东西好好备份。因为后续你每次给RK3576版本升级系统或者重新编译新版ROS2时这套环境都能直接复用不用再从头折腾一遍。我自己就是把这些文件放在一个独立的目录下做了版本管理后面换了新板子或者升级SDK复用这套环境基本没再遇到过第一次那个让人血压飙升的GLIBCXX报错。