搞了这么多年C如果让我给新人列一个“看似没什么技术含量、实际上处处是坑”的操作清单源码编译安装boost库绝对排前三。特别是为了用boost::asio做异步网络编程很多人第一步就卡在编译安装上——环境折腾两三天还没写一行真正的网络代码。这篇就把boost库源码编译安装从头到尾捋一遍包括我这些年踩过的坑、验证过的参数组合、以及编译完成后的工程配置。无论你用Windows还是Linux看完这篇都能顺利把boost装好并且能用asio跑通第一个异步网络示例。1. boost库到底是个什么东西为什么非编译不可1.1 先搞清楚boost的组成结构boost不是一个单一的库而是一大堆C库的集合目前已经有160多个独立库覆盖了智能指针、正则表达式、文件系统、线程、网络、几何计算、图算法等方向。我们重点要用的asio就是其中做异步网络编程的库。这里有个关键概念必须弄明白boost库分为两种形态。一种是header-only也就是只有头文件直接include就能用不需要单独编译链接另一种是必须编译成静态库或动态库才能链接使用。asio本身大部分是header-only但它依赖了boost.system、boost.thread、boost.date_time这些需要编译的库所以你在工程里用asio的时候多多少少还是要链接一些boost的编译产物。这也就是为什么boost不能像普通头文件库一样“解压即用”至少要把依赖的那几个库编译出来。1.2 为什么选择源码编译而不是下载现成二进制很多初学者会问网上不是有编译好的boost安装包吗为什么还要自己编原因有两个。第一boost的二进制包跟编译器的版本、标准库实现绑定得很死。你用MSVC 2022编出来的库放到MSVC 2019的工程里链接阶段很大概率直接报一堆莫名其妙的LNK错误。自己下载源码编译可以做到跟你的工具链完全匹配这是一劳永逸的做法。第二boost的编译选项很灵活。你可以只编译自己需要的库模块可以选静态库或动态库可以指定debug和release版本是否都生成。用别人编好的包这些配置很难自定义。我自己之前就图省事用过预编译包后来项目要从/MT切到/MD整个boost库全部重新编了一遍从那以后再也不碰现成的二进制包了。2. 编译前的准备工作与环境检查2.1 确认编译器工具链boost是用C模板写出来的对编译器版本比较敏感。版本太老的编译器编译boost源码的时候会报一堆模板实例化的错误甚至是编译器内部错误。所以编译之前的首要任务是确认自己的编译器符合要求。Windows平台推荐直接使用Visual Studio 2022或者Visual Studio 2019。注意不只是装IDE一定要勾选“使用C的桌面开发”工作负载确保有MSVC编译器和Windows SDK。装完之后打开“x64 Native Tools Command Prompt for VS 2022”64位原生工具命令行在这个环境里才能编译64位的boost库。Linux平台相对省心一般安装build-essential即可。Ubuntu/Debian系统执行sudo apt update sudo apt install build-essential这里有个细节要提醒boost新版本对编译器的最低版本有要求比如boost 1.84要求GCC 5.4以上、MSVC 14.0以上。如果你用的是老旧的编译器最好先升一下级不然源码编译过程中会卡在一堆不相关的库上而你以为是自己哪里操作错了白白浪费时间。2.2 获取boost源码boost官方的发布途径有两个一是官网下载压缩包二是GitHub上的官方仓库。官网的下载页面会按版本列出文件推荐下载.tar.gz或者.zip格式的源码包。比如要下载1.84.0文件名通常是boost_1_84_0.tar.gz或者boost_1_84_0.zip。GitHub方式则需要拉取指定taggit clone --recursive -b boost-1.84.0 https://github.com/boostorg/boost.git注意这里要用--recursive因为boost仓库包含了很多git子模块不加这个参数拉下来的源码是不完整的编译到一半就会发现缺了某个库的头文件。下载之后的操作也很重要解压路径尽量不要带中文和空格。别问我是怎么知道的当年在Windows上把boost解压到D:\学习资料\boost目录结果b2在扫描路径时报了各种编码错误搞得我以为源码包坏了。2.3 了解boost的版本约定boost的版本命名有规律比如boost_1_84_0对应版本号1.84.0。这个版本号在你后续配置工程时会直接用到因为boost静态库的命名里会带上版本信息比如libboost_system-vc143-mt-x64-1_84.lib最后面的1_84就是版本号。另外boost的版本迭代比较活跃不同版本的编译方式和库依赖会有细微差别。如果你看的教程是几年前的建议还是以当前版本的官方文档为准。我遇到过好几次照着老教程操作却发现新版boost的b2参数已经变了或者某个库模块已经合并到其他库里面了。3. 核心编译流程与关键参数解析3.1 bootstrap与b2的关系boost源码解压之后根目录下会有两个关键文件Windows下是bootstrap.batLinux下是bootstrap.sh。这个bootstrap脚本的作用是生成b2工具。b2是boost的构建引擎它的前身是bjam。它负责读取构建配置、调度编译任务、生成最终的库文件。你不需要单独安装b2直接通过bootstrap脚本生成即可。整个编译流程可以概括为两步运行bootstrap生成b2可执行文件。运行b2传入编译参数编译并安装boost库。很多新手不理解为什么要分两步。其实bootstrap只是个引导程序生成的b2才是最核心的构建引擎相当于先造出一个工具再用这个工具去构建整个库。3.2 核心编译参数逐个拆解b2的参数看起来很多但真正关键的其实就那么几个。我先把最常用的参数列出来并解释每个参数的含义然后再给完整的命令。--build-dir指定编译过程产生的临时文件存放目录建议单独设置不要污染boost源码目录。--stagedir编译完成后生成的库文件的存放目录对应stage方式。--prefix安装目录对应install方式。头文件会被放到prefix/include库文件放到prefix/lib。link指定生成静态库还是动态库。linkstatic生成静态库linkshared生成动态库可以写linkstatic,shared两者都生成。runtime-link指定运行时库的链接方式。runtime-linkstatic对应静态链接C/C运行时runtime-linkshared对应动态链接。variant编译类型可以写variantdebug,release同时编译debug和release版本。address-model指定生成32位还是64位的库address-model64对应64位。threading是否支持多线程threadingmulti是多线程版本一般都要写上。这里特别说一下link和runtime-link的组合问题。在Windows上用MSVC编译时链接时的/MT和/MD选项对应的就是runtime-linkstatic和runtime-linkshared。如果你的工程编译选项是/MD但boost库是runtime-linkstatic编出来的链接时就会遇到运行时库冲突的问题。为了保证省心我一般直接让boost同时生成静态库和动态库且同时生成static和shared的runtime-link这样在任何配置下都能找到匹配的库文件。代价就是编译时间变长磁盘占用变大但换来的是后面用起来不折腾。3.3 模块选择与依赖管理boost全量编译非常耗时我实测过在8核的机器上全量编译1.84.0大概要二十分钟到半小时如果机器性能差一点一个小时以上也是常有的事。而且全量编译出来的库文件会占掉好几个G的磁盘空间其实大部分库我们根本用不到。b2提供了两个参数来控制编译范围--with-库名表示只编译指定模块--without-库名表示编译除了指定模块之外的所有模块。推荐做法是只编译自己需要的模块。针对asio网络编程需要编译的模块至少包括systemasio的错误码和系统调用封装依赖于它。threadasio线程池、strand、定时器等用到了线程相关功能。date_timeasio里的计时器需要用到。regex如果后续做HTTP解析之类的一般会用到正则可以先编上。filesystem虽然不是asio必须但网络通信涉及文件传输时会用到。randomasio的SSL上下文生成随机数时会用到建议一起编。所以编译命令里可以写./b2 --with-system --with-thread --with-date_time --with-regex --with-filesystem --with-random ...如果后续发现缺了什么库再补编一下就好不需要全部重来。3.4 Windows下完整编译步骤Windows下的编译过程我在VS2022环境下实测过多次按下面步骤来基本一次就能编成功。先用管理员身份打开x64 Native Tools Command Prompt for VS 2022然后进入到boost源码根目录执行bootstrapcd D:\libs\boost_1_84_0 bootstrap.bat等待脚本执行完成会在当前目录下生成b2.exe。接着执行编译安装命令b2.exe install ^ --build-dirD:\libs\boost_1_84_0\build ^ --prefixD:\libs\boost_install ^ --with-system --with-thread --with-date_time ^ --with-regex --with-filesystem --with-random ^ variantdebug,release ^ linkstatic,shared ^ runtime-linkstatic,shared ^ threadingmulti ^ address-model64这里解释一下为什么用了install而不是默认的stage。install会把头文件统一复制到prefix/include目录库文件复制到prefix/lib目录相当于完成了一次“安装”后续配置工程时直接指到这个安装目录就行了。stage方式不会复制头文件只会把编译好的库收集到stage/lib目录头文件需要自己到源码目录里找稍微麻烦一点。编译过程会输出大量日志耐心等待即可。编译完成后检查D:\libs\boost_install\include下是否有boost/asio.hpp文件以及lib目录下是否有libboost_system-vc143-mt-x64-1_84.lib这类文件。3.5 Linux下完整编译步骤Linux下的过程跟Windows类似但有几个细节不同。进入到源码根目录后执行cd ~/boost_1_84_0 ./bootstrap.sh --prefix/usr/local--prefix参数可以直接在bootstrap时就指定后续执行b2 install时会用到。当然也可以在b2命令里再指定一遍--prefix效果一样。接着执行sudo ./b2 install \ --build-dir~/boost_1_84_0/build \ --prefix/usr/local \ --with-system --with-thread --with-date_time \ --with-regex --with-filesystem --with-random \ variantdebug,release \ linkstatic,shared \ runtime-linkstatic,shared \ threadingmulti \ address-model64Linux下编译的库文件名跟Windows命名规则不太一样一般是libboost_system.so动态库和libboost_system.a静态库不带编译器版本信息。这是两个平台一个明显的区别Windows下的库文件名里能看到vc143、x64这些标记Linux下很干净看名字只知道库名。编译完成后需要更新一下动态链接库缓存否则运行时可能会找不到boost的so文件sudo ldconfig这一步很容易被忽略但少了它后面编译出来的可执行文件运行时就会报cannot open shared object file的错误。3.6 编译时长与资源规划boost的整体编译对内存和CPU都有一定消耗尤其是模板实例化特别重的模块比如boost::asio、boost::spirit这类编译时单线程内存占用轻松超过1G。8G内存的机器建议不要一次开太多的并行编译任务。可以通过-j参数指定并行编译的线程数一般设置为CPU核心数的1到2倍。比如4核8线程的CPU可以写./b2 -j8 install ...后续参数一样如果是第一次编译心态要放平。即便只编译网络编程相关的几个模块也要几分钟的时间。我见过有人以为编译卡死了直接CtrlC中断然后各种报错。其实看看CPU占用率就知道只要CPU还在跑就没卡死等就完了。4. 实操验证与工程配置4.1 编写第一个asio示例验证安装编译安装完成不等于万事大吉一定要写个示例工程跑通链接确认库真的能用。下面是一个最简单的asio同步定时器示例先把项目跑起来#include iostream #include boost/asio.hpp int main() { boost::asio::io_context io; boost::asio::steady_timer t(io, boost::asio::chrono::seconds(1)); t.wait(); std::cout Hello, boost::asio! std::endl; return 0; }这个demo没有任何网络通信但已经用到了asio的核心对象io_context和定时器能够验证基本链接是否正常。如果这个都跑不过说明boost环境还有问题先排查环境再继续学异步网络编程。4.2 Windows下VS工程配置在Visual Studio里新建一个空项目然后在项目属性里配置以下内容。C/C - 常规 - 附加包含目录填入boost的头文件目录D:\libs\boost_install\include链接器 - 常规 - 附加库目录填入boost的库文件目录D:\libs\boost_install\lib链接器 - 输入 - 附加依赖项根据你实际使用的库手动添加上libboost_system-vc143-mt-x64-1_84.lib libboost_thread-vc143-mt-x64-1_84.lib libboost_date_time-vc143-mt-x64-1_84.lib我自己习惯用静态库所以这里填的lib前缀的静态库文件名。如果编译时用的是动态库运行时需要把对应的DLL放到可执行文件目录或系统PATH里这里不再赘述。还有一点容易踩坑如果你在附加依赖项里写的库文件名跟实际lib目录下的文件名对不上链接器会报LNK1104: cannot open file libboost_system-vc143-mt-x64-1_84.lib。这时候去lib目录下看看实际的文件名一个个对应改过来就好。4.3 Linux下CMake工程配置Linux下用CMake管理C项目是主流做法。下面给一个最小可用的CMakeLists.txt示例cmake_minimum_required(VERSION 3.16) project(asio_demo) set(CMAKE_CXX_STANDARD 17) find_package(Boost REQUIRED COMPONENTS system thread date_time regex filesystem) add_executable(asio_demo main.cpp) target_link_libraries(asio_demo PRIVATE Boost::system Boost::thread Boost::date_time)这里用了find_package(Boost)的方式CMake会自动查找boost的头文件和库文件。前提是CMake能找到boost。如果boost安装到了自定义目录可以在执行cmake时通过-DBOOST_ROOT指定cmake -DBOOST_ROOT~/boost_install ..编译运行mkdir build cd build cmake .. make ./asio_demo看到输出Hello, boost::asio!就说明整个链路已经通了下一步才能真正开始写异步网络代码。4.4 编译模式匹配问题这里再展开讲一个Windows下很常见但很难排查的问题库的编译模式与工程编译模式不匹配。boost库的命名里其实已经包含了很多信息。拿libboost_system-vc143-mt-x64-1_84.lib举例lib前缀表示这是一个静态库。vc143表示是用VS2022的MSVC编译器编译的。mt表示是multithread版本。x64表示是64位目标。1_84表示boost版本是1.84.0。如果你的工程把运行库设置为/MTddebug模式下的静态运行时那就要找对应的-gd标记的库比如libboost_system-vc143-mt-gd-x64-1_84.lib。这个gd表示debug版本。很多新手在debug下链接时报了一堆无法解析的外部符号其实八成是库版本选错了。解决办法很简单——编译boost时同时生成debug和release版本工程切换模式时boost库文件自动匹配对应的库来链接。这也是前面编译参数里写variantdebug,release的原因。5. 常见编译问题与排查技巧实录5.1 fatal error C1083: 无法打开包含文件“Windows.h”这个报错在Windows下很常见原因一般是没有安装Windows SDK或者没有在正确的命令行环境下编译。打开bootstrap命令提示符时一定要用x64 Native Tools Command Prompt for VS 2022而不是普通的cmd。如果是PowerShell需要用Enter-VsDevShell或者直接Visual Studio安装器里的开发者命令行。还有一种情况是你的工程配置里SDK版本没有选。VS在创建工程时会自动选SDK版本但有时新建工程后这个值会变成“继承自父级或项目默认值”此时编译就会找不到Windows.h。手动把SDK版本指定为你安装的Windows SDK版本即可。5.2 b2: command not foundLinux下执行b2命令提示找不到多半是bootstrap步骤没成功。先看下源码根目录下有没有生成b2这个可执行文件。如果没有重新执行bootstrap脚本并注意看输出日志中是否有报错。另一个原因是bootstrap成功生成了b2但你当前shell的PATH没包含当前目录。执行的时候用./b2而不是b2或者在源码根目录下执行就不会有这个困扰了。5.3 链接阶段一堆无法解析的外部符号这个报错大多数情况是boost库与工程的编译参数不匹配。排查思路按照以下顺序确认链接的是64位库工程编译目标也是64位。确认库的debug/release版本与工程当前模式一致。确认库的runtime-link类型与工程的运行库设置一致。确认工程配置里附加依赖项写对了库文件路径。我遇到过最夸张的一次是工程默认是x86平台但boost编的是x64链接时报的错跟上面的几种情况很像排查了半天才发现是平台架构的问题。5.4 编译boost时提示No best alternative for /machine:X86这个报错出现在Windows上直接双击运行bootstrap.bat然后编译的时候原因是b2默认使用当前编译器的默认架构而我的系统是64位默认编译目标却是x86。解决方法是像前面写的那样不要用普通的cmd编译而是用x64 Native Tools Command Prompt for VS 2022。如果已经开了命令行又不想重新开也可以在b2命令里显式加上address-model64让b2强制编译64位库。5.5 动态库编译成功但运行时报找不到DLLWindows下用linkshared编译boost后可执行文件运行时需要对应DLL。如果把这几个DLL拷贝到可执行文件同目录下或者把boost的lib目录加到PATH环境变量里一般都能解决。注意boost的动态库和静态库文件名在Windows下是有前缀区分的动态库通常是boost_system-vc143-mt-x64-1_84.dll不带lib前缀静态库是libboost_system-vc143-mt-x64-1_84.lib。写链接依赖项时一定要看清楚。Linux下也有类似问题如果CMake配置正确但./asio_demo时报找不到libboost_system.so可以先执行ldconfig刷新链接器缓存这在上文Linux编译部分已经提到了。5.6 编译boost时磁盘空间不足boost全量编译的临时文件和最终的库文件都很大。默认编译会在boost源码目录的bin.v2子目录下生成大量中间文件整个目录可能达到几个G。如果磁盘空间不够编译会卡在中间某个环节报错五花八门。建议在b2命令中通过--build-dir把编译中间文件指定到空间充足的磁盘分区编译完成后可以直接把bin.v2目录删掉不影响已安装的boost文件。这个也是我在前面命令里写--build-dir参数的重要原因。6. 我的一些经验与建议6.1 务必先列清楚自己的需求再确定编译参数boost的编译参数组合非常多不同组合生成的库文件不通用。如果一开始不确定用静态库还是动态库好一点的做法是像我前面那样一次编译出static和shared两个版本编译时间虽然长了点但后面用起来不存在无法链接的问题。如果只想要一种那就先想清楚自己的工程会怎么发布。如果你开发的是需要拷贝到其他机器独立运行的工具建议用静态库好处是免去DLL依赖的麻烦。如果你开发的是需要多个程序共享同一份boost库的服务端用动态库可以节省内存占用。6.2 自己维护一个boost编译笔记我自己的习惯是每换一台新机器、或者升级boost版本都会把编译命令保存下来同时在工程里放一份README记录当时的boost版本、编译参数、安装路径。这样就算过了半年再换环境重配照着笔记几分钟就能搞定。开发环境这件事说到底是给自己服务的花点时间记录后面省的都是自己的时间。6.3 不要跳过验证环节很多朋友编译完boost感觉“装好了”然后就一头扎进async代码里结果第一个程序就卡在链接错误上。与其到时候排查半天不如花五分钟写个定时器demo先验证一下环境。这个习惯我在所有C库的编译安装中都会用包括OpenSSL、protobuf等通用的逻辑就是能编、能链、能跑才叫装好。从boost源码编译安装到asio第一个示例跑通整个链路不算短但每一步都值得走扎实。毕竟后面所有异步网络通信的代码都要站在这个地基上面。