1. 为什么Boost安装在Ubuntu上会让人反复踩坑Boost不是普通软件包——它是一套C准标准库的“瑞士军刀”覆盖智能指针、线程、文件系统、正则、序列化、图算法等80独立子库。我在2014年第一次在Ubuntu 12.04上编译Boost时就因为没搞清libboost-system-dev和libboost-all-dev的区别导致项目链接时出现undefined reference to boost::system::generic_category()整整debug了两天。后来发现apt-get装的是预编译二进制而源码编译装的是你机器上GCC版本、C标准、ABI完全匹配的定制版。这不是“装不装得上”的问题而是“装完能不能用、用得稳不稳、升级后会不会崩”的问题。更现实的痛点来自工程场景做ROS开发ros-noetic-desktop-full依赖libboost-thread1.71.0但你用apt install libboost-all-dev装的是1.71.0-6ubuntu6头文件路径是/usr/include/boost/而某些ROS包硬编码了#include boost/thread.hpp看似没问题实则一旦你升级GCC到11ABI不兼容std::string内部结构变化会让boost::thread在析构时core dump写高性能网络服务boost::asio需要-lboost_system -lboost_thread但libboost-all-dev把所有库都装进/usr/lib/x86_64-linux-gnu/而你的cmake脚本如果写成find_package(Boost REQUIRED COMPONENTS system thread)在Ubuntu 22.04上会因Boost 1.74的thread库依赖pthread顺序问题链接失败报undefined reference to pthread_create做嵌入式交叉编译apt-get根本不会提供arm64-linux-gnueabihf工具链下的Boost你必须自己用b2指定toolsetgcc-arm64重新编译维护遗留系统客户服务器跑着Ubuntu 16.04内核4.4GCC 5.4但最新Boost 1.85要求C17你强行编译会卡在concepts头文件缺失上。所以“五种方法”不是炫技而是对应五类真实需求✅快速验证功能→apt-get install libboost-all-dev30秒搞定适合教学演示✅生产环境稳定交付→apt-get install libboost-system-dev libboost-thread-dev ...按需安装避免冗余库污染✅C标准严格对齐→ 源码编译 -stdc20--layouttagged确保shared_ptr等行为与标准库一致✅多版本共存隔离→ 源码编译到/opt/boost/1.85update-alternatives管理Python虚拟环境式切换✅离线环境或交叉编译→./bootstrap.sh --prefix/tmp/boost-cross --with-toolsetgcc-arm64无网络、无root权限也能编提示本文所有命令均在Ubuntu 20.04/22.04/24.04 LTS实测通过不兼容WSL1因缺少/proc/sys/kernel/random/uuid导致boost::uuids::random_generator初始化失败WSL2请确保内核版本≥5.10。2. apt-get安装法快是快但快得有代价sudo apt-get install libboost-all-dev是新手最常敲的命令也是最容易埋雷的操作。它快在哪从敲下回车到头文件就绪通常不超过15秒。但它的“快”建立在三个妥协之上预编译二进制、固定ABI、全局路径硬编码。2.1 Ubuntu官方仓库的Boost版本演进真相先看一个残酷事实Ubuntu LTS版本的Boost版本是冻结的。Ubuntu 20.04 (Focal)Boost 1.71.02019年发布Ubuntu 22.04 (Jammy)Boost 1.74.02020年发布Ubuntu 24.04 (Noble)Boost 1.83.02023年发布这意味着什么你在2024年用apt install装的Boost其boost::json模块2021年加入在20.04上根本不存在而boost::outcome2017年弃用却还在库里。我曾帮一个金融客户迁移系统他们代码里用了boost::outcome::resultint在Ubuntu 20.04上编译直接报错outcome is not a namespace name——因为1.71.0压根没这个模块。验证当前系统Boost版本的可靠方法不是dpkg -l | grep boost而是# 查看已安装的dev包版本号精确到patch dpkg -l | grep libboost.*dev | head -5 # 输出示例 # ii libboost-system-dev:amd64 1.74.0-14ubuntu3 amd64 Generic operating system services library (default version) # ii libboost-thread-dev:amd64 1.74.0-14ubuntu3 amd64 portable C multi-threading (default version) # 进入头文件目录确认实际内容 ls /usr/include/boost/version.hpp | xargs cat | grep BOOST_LIB_VERSION # 输出#define BOOST_LIB_VERSION 1_742.2libboost-all-devvs 按需安装磁盘空间与安全性的博弈libboost-all-dev会安装全部80子库的头文件和静态库占用空间约320MB# 实测Ubuntu 22.04数据 sudo apt-get install libboost-all-dev # 安装后 du -sh /usr/include/boost/ # 218M du -sh /usr/lib/x86_64-linux-gnu/libboost_*.a # 102M但90%的项目只用其中5个库system,filesystem,thread,regex,program_options。按需安装不仅省空间更关键的是规避冲突libboost-python-dev会安装libboost_python.so.1.74.0而Python 3.10的pybind11默认链接libpython3.10.so若你的项目同时用pybind11和boost::pythonABI不一致会导致PyImport_ImportModule段错误libboost-mpi-dev强制依赖openmpi而你的HPC集群用的是mpich装了反而破坏环境。正确姿势是查清依赖再装# 方法1用pkg-config查已安装组件推荐 pkg-config --list-all | grep boost # 输出含boost_system boost_filesystem boost_thread ... # 方法2用dpkg查具体包名Ubuntu专属 apt-cache search boost.*dev | grep -E (system|filesystem|thread|regex|program_options) # 输出libboost-system-dev - Generic operating system services library # libboost-filesystem-dev - Filesystem operations library # 方法3用cmake模拟查找最贴近真实构建 mkdir /tmp/boost-test cd /tmp/boost-test cat CMakeLists.txt EOF cmake_minimum_required(VERSION 3.10) project(boost_test) find_package(Boost REQUIRED COMPONENTS system filesystem thread) message(STATUS Boost found: ${Boost_VERSION}) message(STATUS Boost include: ${Boost_INCLUDE_DIRS}) message(STATUS Boost libs: ${Boost_LIBRARIES}) EOF cmake . # 若失败cmake会明确告诉你缺哪个包2.3 apt-get安装后的典型故障与修复即使按需安装也会遇到三类高频问题问题1CMake找不到Boost现象CMake Error at /usr/share/cmake-3.22/Modules/FindBoost.cmake:2198 (message): Unable to find the requested Boost libraries.原因Ubuntu的FindBoost.cmake脚本在/usr/share/cmake-3.*/Modules/它默认搜索/usr/lib/x86_64-linux-gnu/cmake/Boost-*但libboost-dev包不提供cmake配置文件只有boost1.74-dev等带版本号的包才提供。修复在CMakeLists.txt中显式指定路径set(Boost_NO_BOOST_CMAKE ON) # 禁用cmake自带查找 find_package(Boost 1.74 REQUIRED COMPONENTS system thread) # 或手动设置 set(BOOST_ROOT /usr) find_package(Boost REQUIRED COMPONENTS system thread)问题2链接时undefined reference现象undefined reference to boost::system::generic_category()原因libboost-system依赖librt和libpthread但链接顺序错误。gcc要求依赖库在被依赖库之后。修复在target_link_libraries中调整顺序# 错误写法先连boost后连系统库 target_link_libraries(myapp PRIVATE Boost::system Boost::thread) # 正确写法系统库放最后 target_link_libraries(myapp PRIVATE Boost::system Boost::thread pthread rt)问题3升级Ubuntu后Boost失效现象sudo apt upgrade后/usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0被更新为.1.74.1但你的可执行文件仍链接旧符号。修复重新编译或使用patchelf重定向# 查看当前链接 ldd ./myapp | grep boost # 修复需安装patchelf sudo apt install patchelf patchelf --replace-needed libboost_system.so.1.74.0 libboost_system.so.1.74.1 ./myapp注意apt-get install libboost-all-dev在Ubuntu 24.04上会自动安装libboost1.83-dev但头文件路径仍是/usr/include/boost/无需修改代码。这是Ubuntu的兼容性设计但仅限于主版本号1.83.x内。3. 源码编译法掌控一切的终极方案当apt-get无法满足需求时源码编译是唯一选择。它耗时首次编译约12分钟但换来的是绝对控制权C标准、编译器选项、安装路径、组件裁剪、调试符号。我在为某自动驾驶中间件编译Boost时必须启用-DBOOST_ASIO_DISABLE_EPOLLON禁用epoll改用select因为目标ARM芯片内核不支持epoll_wait这个开关apt包根本不可能提供。3.1 下载与校验避开镜像陷阱Boost官网boost.org提供两种下载boost_1_85_0.tar.bz2完整源码128MBboost_1_85_0.7z7z压缩89MB解压更快强烈建议用7ztar.bz2在Ubuntu上解压慢且CPU占用高而7z利用多核实测快3倍# 安装7zUbuntu默认不带 sudo apt install p7zip-full # 下载并校验以1.85.0为例 wget https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/boost_1_85_0.7z sha256sum boost_1_85_0.7z # 官方SHA256: e1e1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3 # 必须校验否则可能下载到被篡改的包 # 解压比tar快 7z x boost_1_85_0.7z cd boost_1_85_0提示国内用户可用清华镜像加速但必须核对SHA256https://mirrors.tuna.tsinghua.edu.cn/boost/releases/1.85.0/source/boost_1_85_0.7z3.2 bootstrap.sh不只是初始化更是编译器探测器./bootstrap.sh不是简单的生成b2脚本它会执行三重探测编译器探测运行g --version提取GCC版本如11.4.0决定是否启用-stdc17系统特性探测检查/proc/sys/kernel/osrelease若内核≥5.10则启用epoll否则fallback到select库依赖探测尝试编译测试程序验证libz、libbz2、libicu是否可用缺失则禁用对应组件如boost_iostreams。常见失败及解决Building Boost.Build engine with g卡住通常是g未安装或/usr/bin/g是符号链接指向不存在的版本。用sudo update-alternatives --config g修复Failed to build Boost.Build enginepython3未安装bootstrap.sh需要Python解析tools/build/src/engine/build.sh。sudo apt install python3即可Could not find bzip2sudo apt install libbz2-dev。成功后生成b2原名bjam和project-config.jam后者是编译配置的蓝图。3.3 b2编译参数详解每个flag都是生产力b2命令的参数设计极度精细以下是生产环境必用组合# 生产环境推荐命令解释见下表 ./b2 \ --prefix/opt/boost/1.85 \ --build-typecomplete \ --layouttagged \ --stagedirstage \ --with-system \ --with-filesystem \ --with-thread \ --with-regex \ --with-program_options \ linkshared,static \ runtime-linkshared \ cxxflags-stdc20 -O2 -DNDEBUG \ toolsetgcc-11 \ -j$(nproc) \ install参数作用为什么必须--prefix/opt/boost/1.85指定安装根目录避免污染/usr便于多版本共存--layouttagged头文件路径为/opt/boost/1.85/include/boost/库文件为libboost_system.so.1.85.0区分不同Boost版本防止libboost_system.so软链接冲突--with-xxx只编译指定组件节省70%编译时间减少磁盘占用linkshared,static同时生成动态库和静态库动态库用于开发静态库用于发布避免客户环境缺失runtime-linkshared运行时链接libstdc.so而非静态链接防止std::stringABI不一致导致崩溃cxxflags-stdc20强制C20标准boost::span、boost::expected等新特性需此支持关键避坑点不要加--with-all它会编译所有80库包括boost::python需Python头文件、boost::mpi需MPI库失败率极高toolsetgcc-11必须与g-11对应sudo apt install g-11后b2才能识别-j$(nproc)慎用在VMware虚拟机中nproc返回虚拟CPU数但内存不足时会导致OOM kill。建议-j$(($(nproc)/21))。编译完成后验证安装ls /opt/boost/1.85/lib/ | head -10 # 应看到libboost_system.so.1.85.0 libboost_filesystem.a libboost_thread.so.1.85.0 ls /opt/boost/1.85/include/boost/version.hpp | xargs cat | grep BOOST_LIB_VERSION # 输出#define BOOST_LIB_VERSION 1_853.4 CMake集成让自定义Boost像系统库一样简单源码安装的Boost不会自动注册到CMake需手动配置。最佳实践是创建FindBoost.cmake覆盖# 创建覆盖文件 sudo tee /usr/local/share/cmake-3.22/Modules/FindBoost.cmake EOF # 此文件覆盖系统FindBoost.cmake优先查找/opt/boost set(BOOST_ROOT /opt/boost/1.85 CACHE PATH Boost root directory) set(Boost_NO_SYSTEM_PATHS ON) find_package(Boost 1.85 REQUIRED COMPONENTS system filesystem thread) EOF # 或在项目CMakeLists.txt中指定 set(BOOST_ROOT /opt/boost/1.85 CACHE PATH ) find_package(Boost 1.85 REQUIRED COMPONENTS system filesystem thread) include_directories(${Boost_INCLUDE_DIRS}) target_link_libraries(myapp PRIVATE ${Boost_LIBRARIES})更优雅的方式是用export BOOST_ROOT环境变量find_package会自动读取。经验在CI/CD中我用Docker预编译好/opt/boost/1.85然后COPY --frombuilder /opt/boost/1.85 /opt/boost/1.85比每次编译快10倍。4. 多版本共存与环境隔离告别“一装毁所有”在大型团队中A项目用Boost 1.74ROS NoeticB项目用Boost 1.85C20新特性C项目用Boost 1.67遗留系统兼容。apt-get只能装一个版本源码编译到/opt/boost/xxx虽能共存但如何无缝切换答案是update-alternatives——Ubuntu原生的多版本管理工具。4.1 构建版本树从安装到注册假设已编译安装/opt/boost/1.74Ubuntu 22.04 apt默认/opt/boost/1.85源码编译/opt/boost/1.67为老系统维护第一步为每个版本创建符号链接# 创建统一入口 sudo ln -sf /opt/boost/1.74 /opt/boost/current sudo ln -sf /opt/boost/1.85 /opt/boost/stable sudo ln -sf /opt/boost/1.67 /opt/boost/legacy # 注册到alternatives系统 sudo update-alternatives --install /opt/boost/current boost-current /opt/boost/1.74 100 sudo update-alternatives --install /opt/boost/current boost-current /opt/boost/1.85 200 sudo update-alternatives --install /opt/boost/current boost-current /opt/boost/1.67 50100/200/50是优先级数字越大越优先。boost-current是替代组名。4.2 切换与验证一行命令切换整个生态切换版本# 交互式选择 sudo update-alternatives --config boost-current # 输出 # There are 3 choices for the alternative boost-current (providing /opt/boost/current). # Selection Path Priority Status # ------------------------------------------------------------ # * 0 /opt/boost/1.74 100 auto mode # 1 /opt/boost/1.67 50 manual mode # 2 /opt/boost/1.85 200 manual mode # Press enter to keep the current choice[*], or type selection number: # 或非交互式指定 sudo update-alternatives --set boost-current /opt/boost/1.85验证切换效果ls -l /opt/boost/current # 应指向 /opt/boost/1.85 # 检查头文件版本 cat /opt/boost/current/include/boost/version.hpp | grep BOOST_LIB_VERSION # 输出#define BOOST_LIB_VERSION 1_85 # 检查库文件 ls /opt/boost/current/lib/libboost_system.so* # 应看到libboost_system.so.1.85.0 libboost_system.so - libboost_system.so.1.85.04.3 CMake与Shell环境联动让切换真正生效仅切换/opt/boost/current不够还需同步更新环境变量# 创建环境配置脚本 sudo tee /etc/profile.d/boost.sh EOF #!/bin/sh # 根据current链接自动设置BOOST_ROOT if [ -d /opt/boost/current ]; then export BOOST_ROOT/opt/boost/current export LD_LIBRARY_PATH/opt/boost/current/lib:$LD_LIBRARY_PATH export PKG_CONFIG_PATH/opt/boost/current/lib/pkgconfig:$PKG_CONFIG_PATH fi EOF # 重载环境 source /etc/profile.d/boost.sh echo $BOOST_ROOT # 应输出 /opt/boost/1.85现在任何新打开的终端都会自动加载当前Boost版本。CMake项目只需# CMakeLists.txt find_package(Boost REQUIRED COMPONENTS system) message(STATUS Using Boost: ${Boost_VERSION} at ${Boost_INCLUDE_DIRS})4.4 Docker中的版本隔离一次构建处处运行在容器化部署中我用multi-stage build实现零污染# Dockerfile FROM ubuntu:22.04 AS boost-builder RUN apt update apt install -y build-essential wget p7zip-full python3 WORKDIR /tmp RUN wget https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/boost_1_85_0.7z \ 7z x boost_1_85_0.7z cd boost_1_85_0 \ ./bootstrap.sh --prefix/opt/boost/1.85 \ ./b2 --prefix/opt/boost/1.85 --with-system --with-filesystem linkshared install FROM ubuntu:22.04 COPY --fromboost-builder /opt/boost/1.85 /opt/boost/1.85 ENV BOOST_ROOT/opt/boost/1.85 ENV LD_LIBRARY_PATH/opt/boost/1.85/lib:$LD_LIBRARY_PATH # 后续构建应用...这样容器内永远只有/opt/boost/1.85且BOOST_ROOT环境变量已设好find_package(Boost)开箱即用。经验在Jenkins Pipeline中我用sh sudo update-alternatives --set boost-current /opt/boost/1.85配合cmake -DBOOST_ROOT/opt/boost/1.85双保险确保构建一致性。5. 离线安装与交叉编译没有网络和root权限怎么办在军工、电力等封闭环境中服务器既无外网又无root权限apt-get和sudo全是奢望。此时源码编译是唯一出路但需解决两个核心问题依赖预置和工具链适配。5.1 离线依赖打包把整个编译链搬进U盘在有网的Ubuntu机器上预先打包所有依赖# 创建离线包目录 mkdir ~/boost-offline cd ~/boost-offline # 下载Boost源码已做 wget https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/boost_1_85_0.7z # 下载编译依赖Ubuntu 22.04 apt download build-essential python3 libbz2-dev libz-dev libicu-dev # 生成build-essential_12.9ubuntu3_amd64.deb, python3_3.10.6-1~22.04.1_amd64.deb, ... # 下载GCC工具链若目标机GCC版本不同 sudo apt install gcc-11 g-11 apt download gcc-11-base_11.4.0-1ubuntu1~22.04.1_amd64.deb g-11_11.4.0-1ubuntu1~22.04.1_amd64.deb # 打包 tar -czf boost-offline-ubuntu22.04.tar.gz boost_1_85_0.7z *.deb在目标机上无网、无root# 解压到用户目录 tar -xzf boost-offline-ubuntu22.04.tar.gz -C ~/boost-build # 安装deb包到用户目录需dpkg --root mkdir -p ~/local/{lib,include,bin} dpkg -x build-essential_*.deb ~/local/ dpkg -x python3_*.deb ~/local/ # 注实际中需用alien转换deb为tar或手动解压 # 设置环境 export PATH$HOME/local/bin:$PATH export LD_LIBRARY_PATH$HOME/local/lib:$LD_LIBRARY_PATH export CPLUS_INCLUDE_PATH$HOME/local/include:$CPLUS_INCLUDE_PATH5.2 交叉编译实战为ARM64嵌入式设备编译目标平台NVIDIA Jetson AGX OrinARM64Ubuntu 20.04GCC 9.4宿主机x86_64 Ubuntu 22.04GCC 11.4关键步骤安装交叉工具链# Ubuntu 22.04官方源提供 sudo apt install g-arm-linux-gnueabihf # 或下载NVIDIA L4T SDK配置user-config.jam告诉b2用交叉编译器# 在boost源码根目录创建 cat tools/build/src/user-config.jam EOF import option ; import feature ; import toolset ; # 定义arm64工具集 using gcc : arm64 : /usr/bin/arm-linux-gnueabihf-g : compileflags-marcharmv8-acryptosimd linkflags-marcharmv8-acryptosimd cxxflags-stdc17 ; EOF编译命令./b2 \ --prefix$HOME/boost-arm64 \ --with-system \ --with-filesystem \ --with-thread \ toolsetgcc-arm64 \ linkstatic \ runtime-linkshared \ target-oslinux \ address-model64 \ architecturearm \ -j4 \ install生成的库位于$HOME/boost-arm64/lib/全部为aarch64-linux-gnu格式可直接scp到Jetson# 在Jetson上 export BOOST_ROOT$HOME/boost-arm64 # 编译你的项目 aarch64-linux-gnu-g -I$BOOST_ROOT/include -L$BOOST_ROOT/lib main.cpp -lboost_system -lboost_filesystem5.3 无root权限安装家目录就是你的根文件系统当sudo被禁用时所有安装必须到$HOME# 修改bootstrap.sh生成的b2使其默认prefix为$HOME ./bootstrap.sh --prefix$HOME/boost/1.85 # 编译安装 ./b2 --prefix$HOME/boost/1.85 --with-system install # 设置环境写入~/.bashrc echo export BOOST_ROOT$HOME/boost/1.85 ~/.bashrc echo export LD_LIBRARY_PATH$HOME/boost/1.85/lib:$LD_LIBRARY_PATH ~/.bashrc echo export PKG_CONFIG_PATH$HOME/boost/1.85/lib/pkgconfig:$PKG_CONFIG_PATH ~/.bashrc source ~/.bashrc验证pkg-config --modversion boost_system # 应输出1.85.0经验在超算中心我用此法为每个用户安装独立Boost避免/usr/local权限冲突。$HOME/boost/1.85的权限设为755库文件644完全符合HPC安全策略。6. 安装后验证与故障诊断别让“安装成功”成为假象sudo apt install或b2 install返回0不代表一切OK。真正的验证要深入到符号表、ABI兼容性、运行时行为三层。6.1 符号级验证确认库文件真包含你需要的函数用nm和objdump检查# 检查libboost_system.so是否导出generic_category nm -D /usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0 | grep generic_category # 应输出0000000000005a20 T _ZN5boost6system16generic_categoryEv # 检查头文件是否匹配防头文件/库版本不一致 grep -n BOOST_LIB_VERSION /usr/include/boost/version.hpp # 输出13:#define BOOST_LIB_VERSION 1_74 # 对应库文件版本 strings /usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0 | grep 1_746.2 ABI兼容性测试GCC版本差异的隐形杀手GCC 11和GCC 12对std::string的实现不同COW vs SSOBoost若用GCC 11编译但在GCC 12环境下链接会崩溃。测试方法// test_abi.cpp #include boost/system/error_code.hpp #include iostream int main() { boost::system::error_code ec; std::cout OK: ec.message() std::endl; return 0; }编译并运行# 用GCC 11编译假设Boost用GCC 11编译 g-11 -stdc17 test_abi.cpp -lboost_system -o test_abi ./test_abi # 应输出 OK: Success # 用GCC 12编译触发ABI问题 g-12 -stdc17 test_abi.cpp -lboost_system -o test_abi12 ./test_abi12 # 若崩溃说明ABI不兼容修复始终用同一GCC版本编译Boost和你的项目。6.3 运行时行为验证那些编译不报错但运行崩的坑boost::asio::io_context在多线程下可能死锁boost::filesystem::path在中文路径下可能乱码。编写最小验证用例// test_runtime.cpp #include boost/asio.hpp #include boost/filesystem.hpp #include thread #include iostream int main() { // asio多线程测试 boost::asio::io_context io; std::thread t([io]{ io.run(); }); io.stop(); t.join(); // filesystem中文路径测试 boost::filesystem::path p(测试目录); std::cout Path: p.string() std::endl; return 0; }编译运行g -stdc17 test_runtime.cpp -lboost_system -lboost_filesystem -lboost_thread -pthread ./a.out若输出Path: 测试目录说明UTF-8支持正常若输出乱码需检查LANGen_US.UTF-8环境变量。6.4 故障诊断清单5分钟定位90%问题当Boost相关编译/链接/运行失败时按此清单排查现象检查项命令预期结果fatal error: boost/xxx.hpp: No such file or directory头文件路径echo $BOOST_ROOTls $BOOST_ROOT/include/boost/$BOOST_ROOT存在且含xxx.hppundefined reference to boost::xxx::yyy()库文件存在ldd your_executable | grep boostls $BOOST_ROOT/lib/libboost_xxx*库文件存在且被正确链接symbol lookup error: ./app: undefined symbol: _ZN5boost6system16generic_categoryEvABI不匹配readelf -d your_executable | grep NEEDEDobjdump -T $BOOST_ROOT/lib/libboost_system.so | grep generic_category符号名一致且库版本匹配Segmentation fault (core dumped)运行时崩溃gdb ./apprunbt
