简介WonderTrader 依赖库面向在 Ubuntu 环境下编译 WonderTrader 的 C 开发者与量化交易系统搭建者针对 GCC 11.4.0 工具链下常见的第三方依赖缺失、头文件路径分散及 CMake 配置易出错等问题提供可直接复用的依赖集合。压缩包为 tgz 格式共约 2000 个文件其中 1856 个 .hpp、144 个 .h以 C 头文件为主整体约 14.5MB涵盖 JSON 解析、格式化输出、核心工具等常用组件目录组织便于按组件查阅和引用适合离线集成与本地编译。资源说明中给出通过环境变量 MyDependsGcc 指向依赖根目录、并在 CMakeLists.txt 中替换 MyDeps 路径的做法可减少硬编码路径带来的迁移成本方便在不同机器、构建目录或容器中快速切换依赖位置。已有 242 人学习适合需要搭建 WonderTrader 编译环境、排查依赖路径问题、补齐头文件依赖或统一团队编译环境的中高级 C 开发者参考。对需要复现实验环境、快速接入 WonderTrader 项目的读者也更具参考价值。1. 依赖装不全WonderTrader 的头一关是 boost上周在一台空白的 Ubuntu 22.04 机器上跑 WonderTrader 的依赖编译第一次cmake ..直接卡在Could NOT find Boost。补上 boost 之后再跑这次换成 OpenSSL 找不到。第三次是 zlib第四次是 curl。这段断断续续的编译体验干过 C 项目的人应该都懂——它不是难是烦每停一次你都得回去翻一眼日志猜下一个缺的是什么。WonderTrader 这套量化框架的依赖库就是这么个组合git 把源码拉下来boost 负责文件系统、日期时间、线程池和 asio 网络这一层再叠上 OpenSSL、zlib、curl、sqlite3以及 Python 绑定层用到的 dev 头和 swig。少装一个就编译不过版本对不上还会在模板展开阶段给你抛一堆看不懂的报错。这篇记录的是我在这台机器上从系统确认、apt 装依赖、git 拉代码、cmake 配置到装完验证的完整路径适合手里有源码、准备在本机或者服务器上把 WonderTrader 编译起来的开发者新手照着走能跑通熟手可以直接看版本对照和参数取舍。2. 定版本Ubuntu 20.04/22.04 与 Boost、OpenSSL 的搭配2.1 先确认你手上是哪个 Ubuntu 和哪个 gccUbuntu 上编译 WonderTrader系统版本基本决定了你能从 apt 源里拿到的默认 Boost 和 OpenSSL 大版本这不是玄学是源里写死的东西。20.04 默认给 Boost 1.71、OpenSSL 1.1.122.04 给 Boost 1.74、OpenSSL 3.024.04 给 Boost 1.83。这三个组合我都跑过理论上都编得过但 1.71 时代的部分组件接口和后面的差异不小如果源码里用了较新的 asio 写法低版本 boost 会在编译期直接报no matching function而不是链接期才暴露。所以装之前先花三十秒把三件事确认掉系统是哪个 LTS、g 主版本是多少、默认 boost 装没装。# 系统版本确认是 20.04 / 22.04 / 24.04 lsb_release -a # 编译器版本WonderTrader 的 C 部分建议 g 9 以上 g --version gcc --version # 默认 boost 版本和 apt 里可选的版本 dpkg -l | grep -i boost apt-cache policy libboost-devlsb_release -a里的Release字段就是后面选依赖清单的依据g --version看主版本号低于 9 的话建议先升级工具链C14/17 的部分特性在 gcc 7 上会有兼容问题apt-cache policy能直接告诉你源里默认的 boost 版本号不用猜。如果dpkg -l已经有输出说明这台机器以前装过 boost那就要留意后面可能出现的路径冲突这一点在避坑那章会展开。2.2 Boost 装 apt 版还是源码版一张表说清下面这张表是我自己整理的对照左边是系统中间是默认组件版本右边是我一般会怎么选。它不是绝对答案但能帮你少查几次文档。Ubuntu默认 gcc默认 Boost默认 OpenSSL我的装法20.049.41.711.1.1apt 装 boostOpenSSL 用系统版22.0411.41.743.0apt 装 boost最省事24.0413.21.833.0apt 装 boost基本不用动只有在两种情况下我才建议从源码编 Boost一是源码明确要求某个比你系统更新的版本二是 apt 的libboost-all-dev里缺了你要的那个 Python 绑定模块名。除此之外源码编 Boost 的代价是十几分钟编译加上一个容易忘掉的--prefix路径后面 cmake 找不到库时排查成本翻倍。常见做法是能用 apt 就别源码编真需要源码编就把--prefix定到一个固定目录比如/opt/boost后面 cmake 里显式指过去不要往/usr/local里塞避免和系统包混在一起。2.3 一份可以直接抄的 apt 依赖清单确认完版本把下面这条命令整段贴进终端就行。我按功能把它拆成几组方便你理解每个包是干什么的。如果你只想快速跑通直接整段执行。sudo apt update sudo apt install -y \ build-essential cmake git pkg-config \ autoconf automake libtool \ libboost-all-dev \ libssl-dev zlib1g-dev \ libcurl4-openssl-dev libsqlite3-dev \ libpython3-dev python3-dev swig逐组解释一下build-essential cmake git pkg-config是编译工具链cmake 负责生成构建文件pkg-config 在部分依赖探测时会用到autoconf automake libtool是给那些要从源码编译的第三方库准备的现在不装后面补编时会用到libboost-all-dev一次性把 boost 的头文件和所有已编译组件装上这是最省心的做法代价是占几百 MB 磁盘但比缺一个补一个强libssl-dev和zlib1g-dev对应 OpenSSL 和 zlib 的编译头文件注意libssl-dev和运行时包libssl3是两回事只装运行时是编不过的libcurl4-openssl-dev是 curl 的 libcurl 开发包注意别装成libcurl4-nss-dev两者会冲突libsqlite3-dev给本地数据存储用最后一组libpython3-dev python3-dev swig是 Python 绑定层要的如果暂时不需要 Python 接口可以省但建议一次装齐省得回头补。提示装完libboost-all-dev后用dpkg -L libboost-dev | head扫一眼头文件安装位置正常应在/usr/include/boost如果不在说明系统里还有另一份 boost后面 cmake 要显式指定路径。3. git 拉取与依赖落地子模块和编译期依赖3.1 git clone 一定要带 --recursiveWonderTrader 这类项目通常把核心库拆成主仓库加若干子模块子模块里放的可能就是某个网络库或序列化库。直接git clone不带--recursive拉下来的只是主仓库子模块目录是空的cmake 阶段会报某个 include 找不到而你翻遍主仓库都找不到那个头文件——因为它根本不在主仓库里。# 一次性把主仓库和子模块都拉下来 git clone --recursive 你的 WonderTrader 仓库地址 WonderTrader # 如果已经 clone 过但忘了带 --recursive进目录后补这两步 cd WonderTrader git submodule update --init --recursive # 检查子模块是否都到位输出里每个模块前面不应有 - 号 git submodule status--recursive的含义是递归拉取所有层级的子模块子模块里再嵌套子模块也能一次拉全git submodule update --init --recursive是补救命令--init负责把.gitmodules里声明的模块注册进来--recursive负责递归git submodule status的输出里行首是-表示该模块还没初始化是表示本地提交和主仓库记录的不一致两种都要处理后再继续。我一般会在 clone 完先跑一遍 status确认全是空格开头才往下走这样可以避免在 cmake 阶段才发现少东西。3.2 从 apt 补装编译期依赖的顺序依赖不要一次性全装然后指望一次编过我习惯按编译报错的顺序补这样每次补完都知道自己在解决什么。第一轮先装工具链和 boost第二轮补 OpenSSL、zlib、curl第三轮再补 Python 相关。下面是分轮执行的命令你可以一口气跑完也可以按报错逐轮跑。# 第一轮工具链 boost解决 CMakeLists 里 find_package(Boost) 失败 sudo apt install -y build-essential cmake git libboost-all-dev # 第二轮OpenSSL / zlib / curl / sqlite解决编译期头文件缺失 sudo apt install -y libssl-dev zlib1g-dev libcurl4-openssl-dev libsqlite3-dev # 第三轮Python 绑定层的开发头文件和 swig sudo apt install -y libpython3-dev python3-dev swig # 装完刷新一下动态库缓存避免刚装的库 ldd 找不到 sudo ldconfigldconfig这一步很多人会漏它的作用是把新装到/usr/lib/x86_64-linux-gnu下的动态库刷新进系统缓存如果你装上库之后立刻跑程序报error while loading shared libraries八成就是没刷新缓存。libpython3-dev里的 Python 小版本号不用写死apt 会自动选当前系统默认的 Python 3 版本写死libpython3.10-dev之类的反而在换系统后会失效。3.3 什么时候才需要源码编 Boost前面说过能 apt 就别源码编但有些场景绕不开源码里用了boost::asio的新接口而系统 Boost 版本太低或者 Python 绑定那块需要和本机 Python 版本严格对应的libboost_python3xx模块而 apt 里装的模块名对不上。这时候才走源码编译流程如下。# 下载指定版本的 boost 源码包换成你需要的版本号 cd /tmp wget https://archives.boost.io/release/1.83.0/source/boost_1_83_0.tar.gz tar -xzf boost_1_83_0.tar.gz cd boost_1_83_0 # 只编需要的组件prefix 定到独立目录避免污染系统路径 ./bootstrap.sh --prefix/opt/boost \ --with-librariesfilesystem,system,thread,date_time,chrono,regex # -j 后面跟的是并行编译核数机器内存小就降到 2 ./b2 -j$(nproc) linkstatic runtime-linkshared # 安装到 /opt/boost sudo ./b2 install--with-libraries后面列的是要编译的组件不写就是全编全编大概十几分钟只编列出来的几个组件能压到两三分钟linkstatic表示生成静态库runtime-linkshared表示 C 运行时用动态链接这两个参数的取舍主要看你后面是静态链接进可执行文件还是动态加载不确定就保持这个组合--prefix/opt/boost是安装路径编完后的头文件在/opt/boost/include库在/opt/boost/lib后面 cmake 里要显式指过去。编完之后记得把/opt/boost/lib加进LD_LIBRARY_PATH或者干脆在 cmake 里做 rpath 设置不然运行时会找不到刚编的库。4. CMake 配置Boost 路径、编译类型和构建参数4.1 先摸清 cmake 到底去哪找 Boostfind_package(Boost)失败是这套环境最典型的第一枪但失败原因不止一种可能是系统里压根没装可能是装了但 cmake 找的是旧缓存也可能是装了两份 boost 而 cmake 抓到了错的那份。下手之前先看 cmake 的搜索日志不要盲猜。# 让 cmake 打印 Boost 搜索细节看着它到底找了哪些路径 cmake .. -DBoost_DEBUGON # 看看系统里 boost 头文件和库分别在哪 dpkg -L libboost-dev | grep -E include/boost$ dpkg -L libboost-filesystem-dev | grep -E libboost_filesystem # 如果用的是源码编的 boost手动验证那几个目录是否存在 ls /opt/boost/include/boost/version.hpp ls /opt/boost/lib | grep filesystem-DBoost_DEBUGON会把 cmake 搜索 Boost 的每一个候选路径都打出来哪一步找错了、找的是哪个版本一眼能看出来dpkg -L列出某个包安装了哪些文件比盲目find / -name快得多源码编的场景下ls那两行是确认头文件和库文件都在位的最快方式。我一般先在干净的 build 目录里跑一次带Boost_DEBUG的配置把搜索路径确认清楚再去改正式参数。4.2 正式构建的命令和每个参数的含义路径确认完下面是我在 wondertrader 上用的正式 cmake 命令。注意build目录一定要干净否则换了一次 boost 路径后cmake 缓存里还留着老路径会出现明明库在却找不到的怪现象。# 进项目根目录从干净的 build 目录开始 cd WonderTrader rm -rf build mkdir -p build cd build # 生成构建文件Release 优化、显式指定 Boost 路径、指定 Python 解释器 cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DBOOST_ROOT/opt/boost \ -DBoost_NO_SYSTEM_PATHSON \ -DCMAKE_INSTALL_PREFIX/opt/wondertrader \ -DPYTHON_EXECUTABLE$(which python3) # 并行编译核数按内存来定 make -j$(nproc) 21 | tee build.log-DCMAKE_BUILD_TYPERelease是优化级别量化框架对性能敏感别用默认的空值空值时编译器不开优化跑回测会慢得让你怀疑人生-DBOOST_ROOT/opt/boost只在你源码编过 boost、并且装在非系统路径时才需要用 apt 装的就删掉这两行让 cmake 走系统默认搜索-DBoost_NO_SYSTEM_PATHSON让它忽略系统路径只认BOOST_ROOT这是为了避免系统里同时存在 apt 版和源码版时抓错-DCMAKE_INSTALL_PREFIX是make install的安装位置不跑 install 的话这行可省-DPYTHON_EXECUTABLE指定 Python 解释器主要是给后面 Python 绑定层用的不指定时 cmake 可能抓到系统里另一个 Python编出来的模块 import 就报版本不匹配。make -j$(nproc)里的$(nproc)是 CPU 核数-j后面跟多少就用多少核并行编译。这里有个血泪经验核数不是越多越好内存不够的时候多核并行会把系统拖进 OOM编译进程直接被杀日志里只留下一个Killed看上去像玄学实际是内存不够。规则是每核预留 2GB 内存16G 的机器-j8比较稳8G 的机器-j2再少就老老实实单线程。21 | tee build.log是把标准错误也合并到标准输出同时写进日志文件编挂了之后可以直接翻日志找第一个error:不用在滚屏里往回找。4.3 Python 绑定层的依赖补装如果你的构建目标里带 Python 模块cmake 过了之后链接阶段还可能卡住。典型报错是cannot find -lboost_python3xx或者链接上了但 import 时报undefined symbol。原因是 Python 绑定这块对 boost 的 Python 组件版本和 Python 本机版本匹配要求高apt 里的模块名和源码里Boost::python的探测逻辑经常对不上。# 确认系统里到底提供了哪个版本的 boost python 模块 ls /usr/lib/x86_64-linux-gnu/ | grep boost_python # 如果源码编过 boost同时编上 python 组件 cd /tmp/boost_1_83_0 ./bootstrap.sh --prefix/opt/boost --with-python$(which python3) \ --with-librariespython,filesystem,system,thread sudo ./b2 -j4 install # 如果是模块名对不上常见做法是建个软链接把名字对齐别直接改名 sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_python3xx.so \ /usr/lib/x86_64-linux-gnu/libboost_python3.so第一行ls是为了看清系统实际给你的模块名3xx那两位数字随 Python 小版本变化这就是对不上的根源源码编的时候--with-python$(which python3)把本机 Python 传给 bootstrap编出来的模块名就会和本机版本严格对应软链接是应急手段只在确认模块本身存在、纯粹是名字对不上时用改名前先用ldd确认目标文件真实存在否则链接出来的还是断的。这一步做完记得再sudo ldconfig一次然后重新跑一遍 cmake 和 make。5. 避坑五处依赖问题我踩过5.1 报 boost 头文件缺失实际只装了一半现象fatal error: boost/asio.hpp: No such file or directory但dpkg -l | grep boost明明有输出。原因只装了libboost-dev基础头文件没装libboost-all-devasio、filesystem 这些分组件头文件在独立包里。解决直接补sudo apt install -y libboost-all-dev装完再编。不要一个个组件去补一次装全比反复试错省时间。5.2 链接期 undefined reference库顺序问题现象编译通过链接阶段一堆undefined reference to boost::system::...。原因头文件到了但库没链上或者-l参数的顺序在依赖它的目标后面。解决cmake 里用target_link_libraries把 boost 组件放在依赖它的目标后面手动 g 命令的话-lboost_system放在源文件之后。链接顺序是从右往左解析被依赖的放右边。5.3 CMake 抓到了 /usr/local 下的旧 boost现象find_package(Boost)报找到的版本和你dpkg查到的不一致。原因这台机器以前源码编过 boost 并装到/usr/localcmake 的搜索顺序里/usr/local优先于/usr。解决要么在 cmake 里显式-DBOOST_ROOT/usr -DBoost_NO_SYSTEM_PATHSON把路径钉死要么清理/usr/local/include/boost和/usr/local/lib/libboost_*。我一般选前者不删文件改配置更安全。5.4 编译进程被 Killed不是代码问题是内存现象make -j16跑到一半日志突然结束只有一行Killed。原因并行核数超过内存承受范围OOM killer 把编译进程干掉了。解决先降-j到 2 或者直接不带-j内存实在紧的机器临时加 swap# 临时加 4G swap 应急重启后失效 sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile5.5 Python 模块导入报 undefined symbol现象Python 里import wtpy报undefined symbol: _ZN5boost6python...。原因编译链接时的 boost python 库版本和运行环境里的 Python 版本不一致最常见是编译用 Python 3.10运行用 3.8。解决确认-DPYTHON_EXECUTABLE指的和运行环境是同一个解释器python3 -c import sys; print(sys.version)和cmake里指定的路径对一遍对不上就清 build 目录重新 cmake。6. 装完怎么验证从 ldd 到最小可运行程序编完不等于跑得起来这一步是最容易省也最不该省的。我一般按三层来验静态链接检查、动态库解析、最小运行。第一层编译产物存在性和链接依赖。用ldd看可执行文件依赖的动态库是不是全都能解析到not found的一条都不该有。# 找到编译出来的主程序替换成你实际的产物名 file ./bin/WonderTrader # 检查动态库依赖关注输出里的 not found ldd ./bin/WonderTrader | grep -i not found # 如果上面有输出用 ldconfig 刷新缓存后再看一次 sudo ldconfig ldd ./bin/WonderTrader | grep -i not foundfile确认产物架构和链接方式ldd的输出里每行是库名 实际路径出现not found说明运行环境里缺这个库或者路径没进缓存。注意源码编过 boost 的情况LD_LIBRARY_PATH要包含/opt/boost/lib或者用patchelf --set-rpath把路径写进可执行文件后者更稳不依赖环境变量。第二层跑一个最小可执行的入口。很多项目带一个--help或者版本号参数能打出版本信息说明进程能起来、依赖能加载完。# 版本或帮助入口最轻量的一次运行验证 ./bin/WonderTrader --version || ./bin/WonderTrader --help # 看看退出码0 才算正常 echo $?这一步能过说明动态库加载链路是通的。如果卡在这里回到上一层的ldd输出逐条排查别急着去看业务代码。第三层也是最容易被忽略的一层用一个最小的配置跑一次加载。WonderTrader 启动要读配置文件配置文件里涉及的插件和路径如果配错程序会在初始化阶段退出。试运行的日志要完整看一遍别只看最后一行。# 用一个最小配置跑一次日志同时存文件 ./bin/WonderTrader -c ./config/minimal.yaml run.log 21 tail -n 50 run.log # 检查日志里有没有加载失败的插件或库 grep -iE error|fail|not found|undefined run.log第三层过了才算真正把这套依赖装明白了。下面这张表是我验证时常用的对照出现问题时按列去定位比拍脑袋快。验证层级检查命令正常表现异常时先看哪产物file ./bin/...显示 ELF 64-bit 可执行产物名或构建是否成功依赖ldd ./bin/...无 not foundLD_LIBRARY_PATH、ldconfig运行--version/--help正常输出、退出码 0动态库加载顺序配置带配置启动日志无 error/fail配置路径、插件依赖那次在这台 22.04 上装完我最大的教训是别信“编译通过就完事”的错觉。第一次ldd扫出三个not found全是源码编 boost 之后没刷新缓存导致编译阶段一切正常运行阶段直接崩。从那以后我每次装完依赖都强制走一遍“ldd 扫一遍、最小入口跑一遍、日志 grep 一遍”这三步花不了两分钟但能把后面几个小时的环境排错挡在前面。这套依赖清单和配置片段我整理在一起了照着上面的顺序走一遍基本能复现希望帮到你。本文还有配套的精品资源点击获取
简介WonderTrader 依赖库面向在 Ubuntu 环境下编译 WonderTrader 的 C 开发者与量化交易系统搭建者针对 GCC 11.4.0 工具链下常见的第三方依赖缺失、头文件路径分散及 CMake 配置易出错等问题提供可直接复用的依赖集合。压缩包为 tgz 格式共约 2000 个文件其中 1856 个 .hpp、144 个 .h以 C 头文件为主整体约 14.5MB涵盖 JSON 解析、格式化输出、核心工具等常用组件目录组织便于按组件查阅和引用适合离线集成与本地编译。资源说明中给出通过环境变量 MyDependsGcc 指向依赖根目录、并在 CMakeLists.txt 中替换 MyDeps 路径的做法可减少硬编码路径带来的迁移成本方便在不同机器、构建目录或容器中快速切换依赖位置。已有 242 人学习适合需要搭建 WonderTrader 编译环境、排查依赖路径问题、补齐头文件依赖或统一团队编译环境的中高级 C 开发者参考。对需要复现实验环境、快速接入 WonderTrader 项目的读者也更具参考价值。1. 依赖装不全WonderTrader 的头一关是 boost上周在一台空白的 Ubuntu 22.04 机器上跑 WonderTrader 的依赖编译第一次cmake ..直接卡在Could NOT find Boost。补上 boost 之后再跑这次换成 OpenSSL 找不到。第三次是 zlib第四次是 curl。这段断断续续的编译体验干过 C 项目的人应该都懂——它不是难是烦每停一次你都得回去翻一眼日志猜下一个缺的是什么。WonderTrader 这套量化框架的依赖库就是这么个组合git 把源码拉下来boost 负责文件系统、日期时间、线程池和 asio 网络这一层再叠上 OpenSSL、zlib、curl、sqlite3以及 Python 绑定层用到的 dev 头和 swig。少装一个就编译不过版本对不上还会在模板展开阶段给你抛一堆看不懂的报错。这篇记录的是我在这台机器上从系统确认、apt 装依赖、git 拉代码、cmake 配置到装完验证的完整路径适合手里有源码、准备在本机或者服务器上把 WonderTrader 编译起来的开发者新手照着走能跑通熟手可以直接看版本对照和参数取舍。2. 定版本Ubuntu 20.04/22.04 与 Boost、OpenSSL 的搭配2.1 先确认你手上是哪个 Ubuntu 和哪个 gccUbuntu 上编译 WonderTrader系统版本基本决定了你能从 apt 源里拿到的默认 Boost 和 OpenSSL 大版本这不是玄学是源里写死的东西。20.04 默认给 Boost 1.71、OpenSSL 1.1.122.04 给 Boost 1.74、OpenSSL 3.024.04 给 Boost 1.83。这三个组合我都跑过理论上都编得过但 1.71 时代的部分组件接口和后面的差异不小如果源码里用了较新的 asio 写法低版本 boost 会在编译期直接报no matching function而不是链接期才暴露。所以装之前先花三十秒把三件事确认掉系统是哪个 LTS、g 主版本是多少、默认 boost 装没装。# 系统版本确认是 20.04 / 22.04 / 24.04 lsb_release -a # 编译器版本WonderTrader 的 C 部分建议 g 9 以上 g --version gcc --version # 默认 boost 版本和 apt 里可选的版本 dpkg -l | grep -i boost apt-cache policy libboost-devlsb_release -a里的Release字段就是后面选依赖清单的依据g --version看主版本号低于 9 的话建议先升级工具链C14/17 的部分特性在 gcc 7 上会有兼容问题apt-cache policy能直接告诉你源里默认的 boost 版本号不用猜。如果dpkg -l已经有输出说明这台机器以前装过 boost那就要留意后面可能出现的路径冲突这一点在避坑那章会展开。2.2 Boost 装 apt 版还是源码版一张表说清下面这张表是我自己整理的对照左边是系统中间是默认组件版本右边是我一般会怎么选。它不是绝对答案但能帮你少查几次文档。Ubuntu默认 gcc默认 Boost默认 OpenSSL我的装法20.049.41.711.1.1apt 装 boostOpenSSL 用系统版22.0411.41.743.0apt 装 boost最省事24.0413.21.833.0apt 装 boost基本不用动只有在两种情况下我才建议从源码编 Boost一是源码明确要求某个比你系统更新的版本二是 apt 的libboost-all-dev里缺了你要的那个 Python 绑定模块名。除此之外源码编 Boost 的代价是十几分钟编译加上一个容易忘掉的--prefix路径后面 cmake 找不到库时排查成本翻倍。常见做法是能用 apt 就别源码编真需要源码编就把--prefix定到一个固定目录比如/opt/boost后面 cmake 里显式指过去不要往/usr/local里塞避免和系统包混在一起。2.3 一份可以直接抄的 apt 依赖清单确认完版本把下面这条命令整段贴进终端就行。我按功能把它拆成几组方便你理解每个包是干什么的。如果你只想快速跑通直接整段执行。sudo apt update sudo apt install -y \ build-essential cmake git pkg-config \ autoconf automake libtool \ libboost-all-dev \ libssl-dev zlib1g-dev \ libcurl4-openssl-dev libsqlite3-dev \ libpython3-dev python3-dev swig逐组解释一下build-essential cmake git pkg-config是编译工具链cmake 负责生成构建文件pkg-config 在部分依赖探测时会用到autoconf automake libtool是给那些要从源码编译的第三方库准备的现在不装后面补编时会用到libboost-all-dev一次性把 boost 的头文件和所有已编译组件装上这是最省心的做法代价是占几百 MB 磁盘但比缺一个补一个强libssl-dev和zlib1g-dev对应 OpenSSL 和 zlib 的编译头文件注意libssl-dev和运行时包libssl3是两回事只装运行时是编不过的libcurl4-openssl-dev是 curl 的 libcurl 开发包注意别装成libcurl4-nss-dev两者会冲突libsqlite3-dev给本地数据存储用最后一组libpython3-dev python3-dev swig是 Python 绑定层要的如果暂时不需要 Python 接口可以省但建议一次装齐省得回头补。提示装完libboost-all-dev后用dpkg -L libboost-dev | head扫一眼头文件安装位置正常应在/usr/include/boost如果不在说明系统里还有另一份 boost后面 cmake 要显式指定路径。3. git 拉取与依赖落地子模块和编译期依赖3.1 git clone 一定要带 --recursiveWonderTrader 这类项目通常把核心库拆成主仓库加若干子模块子模块里放的可能就是某个网络库或序列化库。直接git clone不带--recursive拉下来的只是主仓库子模块目录是空的cmake 阶段会报某个 include 找不到而你翻遍主仓库都找不到那个头文件——因为它根本不在主仓库里。# 一次性把主仓库和子模块都拉下来 git clone --recursive 你的 WonderTrader 仓库地址 WonderTrader # 如果已经 clone 过但忘了带 --recursive进目录后补这两步 cd WonderTrader git submodule update --init --recursive # 检查子模块是否都到位输出里每个模块前面不应有 - 号 git submodule status--recursive的含义是递归拉取所有层级的子模块子模块里再嵌套子模块也能一次拉全git submodule update --init --recursive是补救命令--init负责把.gitmodules里声明的模块注册进来--recursive负责递归git submodule status的输出里行首是-表示该模块还没初始化是表示本地提交和主仓库记录的不一致两种都要处理后再继续。我一般会在 clone 完先跑一遍 status确认全是空格开头才往下走这样可以避免在 cmake 阶段才发现少东西。3.2 从 apt 补装编译期依赖的顺序依赖不要一次性全装然后指望一次编过我习惯按编译报错的顺序补这样每次补完都知道自己在解决什么。第一轮先装工具链和 boost第二轮补 OpenSSL、zlib、curl第三轮再补 Python 相关。下面是分轮执行的命令你可以一口气跑完也可以按报错逐轮跑。# 第一轮工具链 boost解决 CMakeLists 里 find_package(Boost) 失败 sudo apt install -y build-essential cmake git libboost-all-dev # 第二轮OpenSSL / zlib / curl / sqlite解决编译期头文件缺失 sudo apt install -y libssl-dev zlib1g-dev libcurl4-openssl-dev libsqlite3-dev # 第三轮Python 绑定层的开发头文件和 swig sudo apt install -y libpython3-dev python3-dev swig # 装完刷新一下动态库缓存避免刚装的库 ldd 找不到 sudo ldconfigldconfig这一步很多人会漏它的作用是把新装到/usr/lib/x86_64-linux-gnu下的动态库刷新进系统缓存如果你装上库之后立刻跑程序报error while loading shared libraries八成就是没刷新缓存。libpython3-dev里的 Python 小版本号不用写死apt 会自动选当前系统默认的 Python 3 版本写死libpython3.10-dev之类的反而在换系统后会失效。3.3 什么时候才需要源码编 Boost前面说过能 apt 就别源码编但有些场景绕不开源码里用了boost::asio的新接口而系统 Boost 版本太低或者 Python 绑定那块需要和本机 Python 版本严格对应的libboost_python3xx模块而 apt 里装的模块名对不上。这时候才走源码编译流程如下。# 下载指定版本的 boost 源码包换成你需要的版本号 cd /tmp wget https://archives.boost.io/release/1.83.0/source/boost_1_83_0.tar.gz tar -xzf boost_1_83_0.tar.gz cd boost_1_83_0 # 只编需要的组件prefix 定到独立目录避免污染系统路径 ./bootstrap.sh --prefix/opt/boost \ --with-librariesfilesystem,system,thread,date_time,chrono,regex # -j 后面跟的是并行编译核数机器内存小就降到 2 ./b2 -j$(nproc) linkstatic runtime-linkshared # 安装到 /opt/boost sudo ./b2 install--with-libraries后面列的是要编译的组件不写就是全编全编大概十几分钟只编列出来的几个组件能压到两三分钟linkstatic表示生成静态库runtime-linkshared表示 C 运行时用动态链接这两个参数的取舍主要看你后面是静态链接进可执行文件还是动态加载不确定就保持这个组合--prefix/opt/boost是安装路径编完后的头文件在/opt/boost/include库在/opt/boost/lib后面 cmake 里要显式指过去。编完之后记得把/opt/boost/lib加进LD_LIBRARY_PATH或者干脆在 cmake 里做 rpath 设置不然运行时会找不到刚编的库。4. CMake 配置Boost 路径、编译类型和构建参数4.1 先摸清 cmake 到底去哪找 Boostfind_package(Boost)失败是这套环境最典型的第一枪但失败原因不止一种可能是系统里压根没装可能是装了但 cmake 找的是旧缓存也可能是装了两份 boost 而 cmake 抓到了错的那份。下手之前先看 cmake 的搜索日志不要盲猜。# 让 cmake 打印 Boost 搜索细节看着它到底找了哪些路径 cmake .. -DBoost_DEBUGON # 看看系统里 boost 头文件和库分别在哪 dpkg -L libboost-dev | grep -E include/boost$ dpkg -L libboost-filesystem-dev | grep -E libboost_filesystem # 如果用的是源码编的 boost手动验证那几个目录是否存在 ls /opt/boost/include/boost/version.hpp ls /opt/boost/lib | grep filesystem-DBoost_DEBUGON会把 cmake 搜索 Boost 的每一个候选路径都打出来哪一步找错了、找的是哪个版本一眼能看出来dpkg -L列出某个包安装了哪些文件比盲目find / -name快得多源码编的场景下ls那两行是确认头文件和库文件都在位的最快方式。我一般先在干净的 build 目录里跑一次带Boost_DEBUG的配置把搜索路径确认清楚再去改正式参数。4.2 正式构建的命令和每个参数的含义路径确认完下面是我在 wondertrader 上用的正式 cmake 命令。注意build目录一定要干净否则换了一次 boost 路径后cmake 缓存里还留着老路径会出现明明库在却找不到的怪现象。# 进项目根目录从干净的 build 目录开始 cd WonderTrader rm -rf build mkdir -p build cd build # 生成构建文件Release 优化、显式指定 Boost 路径、指定 Python 解释器 cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DBOOST_ROOT/opt/boost \ -DBoost_NO_SYSTEM_PATHSON \ -DCMAKE_INSTALL_PREFIX/opt/wondertrader \ -DPYTHON_EXECUTABLE$(which python3) # 并行编译核数按内存来定 make -j$(nproc) 21 | tee build.log-DCMAKE_BUILD_TYPERelease是优化级别量化框架对性能敏感别用默认的空值空值时编译器不开优化跑回测会慢得让你怀疑人生-DBOOST_ROOT/opt/boost只在你源码编过 boost、并且装在非系统路径时才需要用 apt 装的就删掉这两行让 cmake 走系统默认搜索-DBoost_NO_SYSTEM_PATHSON让它忽略系统路径只认BOOST_ROOT这是为了避免系统里同时存在 apt 版和源码版时抓错-DCMAKE_INSTALL_PREFIX是make install的安装位置不跑 install 的话这行可省-DPYTHON_EXECUTABLE指定 Python 解释器主要是给后面 Python 绑定层用的不指定时 cmake 可能抓到系统里另一个 Python编出来的模块 import 就报版本不匹配。make -j$(nproc)里的$(nproc)是 CPU 核数-j后面跟多少就用多少核并行编译。这里有个血泪经验核数不是越多越好内存不够的时候多核并行会把系统拖进 OOM编译进程直接被杀日志里只留下一个Killed看上去像玄学实际是内存不够。规则是每核预留 2GB 内存16G 的机器-j8比较稳8G 的机器-j2再少就老老实实单线程。21 | tee build.log是把标准错误也合并到标准输出同时写进日志文件编挂了之后可以直接翻日志找第一个error:不用在滚屏里往回找。4.3 Python 绑定层的依赖补装如果你的构建目标里带 Python 模块cmake 过了之后链接阶段还可能卡住。典型报错是cannot find -lboost_python3xx或者链接上了但 import 时报undefined symbol。原因是 Python 绑定这块对 boost 的 Python 组件版本和 Python 本机版本匹配要求高apt 里的模块名和源码里Boost::python的探测逻辑经常对不上。# 确认系统里到底提供了哪个版本的 boost python 模块 ls /usr/lib/x86_64-linux-gnu/ | grep boost_python # 如果源码编过 boost同时编上 python 组件 cd /tmp/boost_1_83_0 ./bootstrap.sh --prefix/opt/boost --with-python$(which python3) \ --with-librariespython,filesystem,system,thread sudo ./b2 -j4 install # 如果是模块名对不上常见做法是建个软链接把名字对齐别直接改名 sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_python3xx.so \ /usr/lib/x86_64-linux-gnu/libboost_python3.so第一行ls是为了看清系统实际给你的模块名3xx那两位数字随 Python 小版本变化这就是对不上的根源源码编的时候--with-python$(which python3)把本机 Python 传给 bootstrap编出来的模块名就会和本机版本严格对应软链接是应急手段只在确认模块本身存在、纯粹是名字对不上时用改名前先用ldd确认目标文件真实存在否则链接出来的还是断的。这一步做完记得再sudo ldconfig一次然后重新跑一遍 cmake 和 make。5. 避坑五处依赖问题我踩过5.1 报 boost 头文件缺失实际只装了一半现象fatal error: boost/asio.hpp: No such file or directory但dpkg -l | grep boost明明有输出。原因只装了libboost-dev基础头文件没装libboost-all-devasio、filesystem 这些分组件头文件在独立包里。解决直接补sudo apt install -y libboost-all-dev装完再编。不要一个个组件去补一次装全比反复试错省时间。5.2 链接期 undefined reference库顺序问题现象编译通过链接阶段一堆undefined reference to boost::system::...。原因头文件到了但库没链上或者-l参数的顺序在依赖它的目标后面。解决cmake 里用target_link_libraries把 boost 组件放在依赖它的目标后面手动 g 命令的话-lboost_system放在源文件之后。链接顺序是从右往左解析被依赖的放右边。5.3 CMake 抓到了 /usr/local 下的旧 boost现象find_package(Boost)报找到的版本和你dpkg查到的不一致。原因这台机器以前源码编过 boost 并装到/usr/localcmake 的搜索顺序里/usr/local优先于/usr。解决要么在 cmake 里显式-DBOOST_ROOT/usr -DBoost_NO_SYSTEM_PATHSON把路径钉死要么清理/usr/local/include/boost和/usr/local/lib/libboost_*。我一般选前者不删文件改配置更安全。5.4 编译进程被 Killed不是代码问题是内存现象make -j16跑到一半日志突然结束只有一行Killed。原因并行核数超过内存承受范围OOM killer 把编译进程干掉了。解决先降-j到 2 或者直接不带-j内存实在紧的机器临时加 swap# 临时加 4G swap 应急重启后失效 sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile5.5 Python 模块导入报 undefined symbol现象Python 里import wtpy报undefined symbol: _ZN5boost6python...。原因编译链接时的 boost python 库版本和运行环境里的 Python 版本不一致最常见是编译用 Python 3.10运行用 3.8。解决确认-DPYTHON_EXECUTABLE指的和运行环境是同一个解释器python3 -c import sys; print(sys.version)和cmake里指定的路径对一遍对不上就清 build 目录重新 cmake。6. 装完怎么验证从 ldd 到最小可运行程序编完不等于跑得起来这一步是最容易省也最不该省的。我一般按三层来验静态链接检查、动态库解析、最小运行。第一层编译产物存在性和链接依赖。用ldd看可执行文件依赖的动态库是不是全都能解析到not found的一条都不该有。# 找到编译出来的主程序替换成你实际的产物名 file ./bin/WonderTrader # 检查动态库依赖关注输出里的 not found ldd ./bin/WonderTrader | grep -i not found # 如果上面有输出用 ldconfig 刷新缓存后再看一次 sudo ldconfig ldd ./bin/WonderTrader | grep -i not foundfile确认产物架构和链接方式ldd的输出里每行是库名 实际路径出现not found说明运行环境里缺这个库或者路径没进缓存。注意源码编过 boost 的情况LD_LIBRARY_PATH要包含/opt/boost/lib或者用patchelf --set-rpath把路径写进可执行文件后者更稳不依赖环境变量。第二层跑一个最小可执行的入口。很多项目带一个--help或者版本号参数能打出版本信息说明进程能起来、依赖能加载完。# 版本或帮助入口最轻量的一次运行验证 ./bin/WonderTrader --version || ./bin/WonderTrader --help # 看看退出码0 才算正常 echo $?这一步能过说明动态库加载链路是通的。如果卡在这里回到上一层的ldd输出逐条排查别急着去看业务代码。第三层也是最容易被忽略的一层用一个最小的配置跑一次加载。WonderTrader 启动要读配置文件配置文件里涉及的插件和路径如果配错程序会在初始化阶段退出。试运行的日志要完整看一遍别只看最后一行。# 用一个最小配置跑一次日志同时存文件 ./bin/WonderTrader -c ./config/minimal.yaml run.log 21 tail -n 50 run.log # 检查日志里有没有加载失败的插件或库 grep -iE error|fail|not found|undefined run.log第三层过了才算真正把这套依赖装明白了。下面这张表是我验证时常用的对照出现问题时按列去定位比拍脑袋快。验证层级检查命令正常表现异常时先看哪产物file ./bin/...显示 ELF 64-bit 可执行产物名或构建是否成功依赖ldd ./bin/...无 not foundLD_LIBRARY_PATH、ldconfig运行--version/--help正常输出、退出码 0动态库加载顺序配置带配置启动日志无 error/fail配置路径、插件依赖那次在这台 22.04 上装完我最大的教训是别信“编译通过就完事”的错觉。第一次ldd扫出三个not found全是源码编 boost 之后没刷新缓存导致编译阶段一切正常运行阶段直接崩。从那以后我每次装完依赖都强制走一遍“ldd 扫一遍、最小入口跑一遍、日志 grep 一遍”这三步花不了两分钟但能把后面几个小时的环境排错挡在前面。这套依赖清单和配置片段我整理在一起了照着上面的顺序走一遍基本能复现希望帮到你。本文还有配套的精品资源点击获取
