由于要跑出代码SfM-Toy-Library
https://github.com/royshil/SfM-Toy-Library
Prerequisite
- OpenCV 3.x: http://www.opencv.org
- Ceres Solver (for bundle adjustment): http://ceres-solver.org/
- Boost C++ libraries v1.54+: http://www.boost.org/
需求中用到了Boost库，我在官网下载了已经编译好的Windows二进制文件
下载地址为：https://sourceforge.net/projects/boost/files/boost-binaries/
我下载的是最新的boost1.67
boost_1_67_0-msvc-12.0-64.exe
既有boost，也有libboost，接下来，我们来搞清出，这些都是什么
注意：使用boost库是，要添加path路径
比如当前项目：D:\SfM-Toy-Library-master\boost_1_67_0\lib64-msvc-12.0
Boost库的命名
官方出处：https://www.boost.org/doc/libs/1_38_0/more/getting_started/windows.html
以 libboost_regex-vc71-mt-d-1_34.lib 为例：
- lib
前缀：除了Microsoft Windows之外，每一个Boost库的名字都以此字符串开始。在Windows上，只有普通的静态库使用lib前缀；导入库和DLL不使用。 - boost_regex
库名称：所有boost库名文件以boost_开头。 - -vc71
Toolset 标记：标识了构建该库所用的toolset和版本。 - -mt
Threading 标记：标识构建该库启用了多线程支持。不支持多线程的库没有-mt。 - -d
ABI标记：编码了影响库和其他编译代码交互的细节。对于每一种特性，向标记中添加一个字母：Key Use this library when: s 静态链接到C++标准库和编译器运行时支撑库 g 使用标准库和运行时支撑库的调试版本 y 使用Python的特殊调试构建 d 构建代码的调试版本 p 使用STLPort标准库而不是编译器提供的默认库 n 使用STLPort已被弃用的“native iostreams” - -1_34
版本标记：完整的Boost发布号，下划线代替点。例如，1.31.1版本将被标记为“-1_31_1”。 - .lib
扩展名：取决于操作系统。在大多数unix平台上，.a是静态库，.so是共享库。在Windows上，.dll表示共享库，.lib是静态或导入库。
下表是对Regex库编译后的文件名：
| 文件名 | 含义 | 编译使用该库的程序时应使用的编译选项 |
| libboost_regex-vc90-mt-sgd-1_38.lib | 静态库，多线程，调试版本 使用静态调试版本C运行时库（LIBCMTD.LIB和LIBCPMTD.LIB） |
/MTd |
| libboost_regex-vc90-mt-s-1_38.lib | 静态库，多线程 使用静态版本C运行时库（LIBCMT.LIB和LIBCPMT.LIB） |
/MT |
| libboost_regex-vc90-mt-gd-1_38.lib | 静态库，多线程，调试版本 使用动态调试版本C运行时库（MSVCRTD.LIB和MSVCPRTD.LIB） |
/MDd |
| libboost_regex-vc90-mt-1_38.lib | 静态库，多线程 使用动态版本C运行时库（MSVCRT.LIB和MSVCPRT.LIB） |
/MD |
| boost_regex-vc90-mt-gd-1_38.lib | 导入库（boost_regex-vc90-mt-gd-1_38.dll），多线程，调试版本 | |
| boost_regex-vc90-mt-1_38.lib | 导入库（boost_regex-vc90-mt-1_38.dll）多线程 |
需要注意的是，链接时，所使用的Regex库文件名必须和编译选项匹配，否则会造成如下链接错误：
LINK : warning LNK4098: defaultlib '×××××' conflicts with use of other libs; use /NODEFAULTLIB:library
原因是，当编译时，cl.exe（也就是VC的编译器）会根据上述编译选项在编译成的obj文件中植入相应的defaultlib文件名（使用DUMPBIN /DIRECTIVE***,lib可以查看），如/MT对应的就是LIBCMT.LIB（C）和LIBCPMT.LIB（C++标准库）。当链接器处理该obj文件时，会从文件中取出该defaultlib文件名，将其放在命令行库列表的最后以供使用。对于静态库的处理也是如此，静态库也是由一些obj文件组成的，每个obj文件中也根据当时的编译选项被植入了相应的defaultlib。当链接器处理静态库时，也会将涉及到的obj文件中的defaultlib放在命令行库列表的最后。假设，我们的程序使用/MT编译，那个对应的defaultlib就是LIBCMT.LIB（C）和LIBCPMT.LIB（C++标准库）。而使用的是libboost_regex-vc90-mt-sgd-1_38.lib，它对应的defaultlib就是LIBCMTD.LIB和LIBCPMTD.LIB。链接过程中，链接器会发现采用了不同的运行时库，所以会出现上述错误。
幸运的是，Visual C++支持自动链接，当包含Regex的头文件时，Regex会根据当前工程的编译选项（不同的编译选项会定义不同的宏，具体参见上一篇C运行时库）自动告诉编译器将哪个文件送给链接器。
Boost.Regex默认使用的静态链接方式，如果希望使用动态链接方式，如何实现呢？ 定义宏BOOST_REGEX_DYN_LINK。要注意，一定要在包含regex头文件之前定义该宏：
如果还有不明白，可参考博文：Boost安装的安装，以及在VS2013下的使用
博客地址：https://www.cnblogs.com/icmzn/p/5911073.html
| 序号 | link 设置 | Runtime设置 | 生成文件区别 (Debug,Release)两个版本 | 备注 |
| 1 | static | static | libboost_date_time-vc120-mt-sgd-1_56.lib libboost_date_time-vc120-mt-s-1_56.lib |
|
| 2 | static | shared | libboost_date_time-vc120-mt-gd-1_56.lib libboost_date_time-vc120-mt-1_56.lib |
（缺省的配置） |
| 3 | shared | shared | boost_date_time-vc120-mt-gd-1_56.dll boost_date_time-vc120-mt-gd-1_56.lib boost_date_time-vc120-mt-1_56.dll boost_date_time-vc120-mt-1_56.lib |
|
| 4 | shared | static | 不能编译 | |
| 5 | 使用缺省 | 使用缺省 | libboost_date_time-vc120-mt-gd-1_56.lib libboost_date_time-vc120-mt-1_56.lib |
（与2结果相同） |
| 6 | 使用--build-type=complete | boost_date_time-vc120-mt-gd-1_56.dll boost_date_time-vc120-mt-gd-1_56.lib boost_date_time-vc120-mt-1_56.dll boost_date_time-vc120-mt-1_56.lib libboost_date_time-vc120-mt-sgd-1_56.lib libboost_date_time-vc120-mt-s-1_56.lib libboost_date_time-vc120-mt-gd-1_56.lib libboost_date_time-vc120-mt-1_56.lib libboost_date_time-vc120-s-1_56.lib libboost_date_time-vc120-sgd-1_56.lib |
说明：
（1）--build-type=complete时link，runtime-link3种组合下debug， release的多线程版本都生成出来了除此之外还生成了link=static，runtime-link=static的debug， release的单线程版本
（2）Boost库的使用方式link决定了生成的库的格式：lib（静态链接库-static）， dll（动态链接库-share）
当link是static时，生成的静态库： libboost_*****.lib
当link是share时，生成的动态链接库：boost_****.dll
（3）Boost库的编译中runtime-link，决定了生成库与C/C++库的连接方式
当runtime-link是static使： 生成的库文件名有 s
当runtime-link是share使： 生成的库文件名没有s
（4）link以及与runtime-link缺省的设置是：
link是静态的（便于整合到应用中，避免单独移动boost的相关动态连接库）
runtime-link是share的，这样可以动态调用c/C++运行时库，方便
（5）degug版本的库名称： 含有gd
release版本中的库名称；不含有gd
（6）threading，设置mutl 多线程的库，则库名称包含：mutl
如果是单线程，则没有mutl
（7）我们还可以分析一下 boost 库的命名特点
- 以“lib”开头的是“link=static”版本（静态链接库版本，没有dll），而直接以“boost”开头的是“link=shared”版本（动态链接库版本，包含lib和dll）。
- 所有的库都含有"boost"前缀。
- 紧随其后的是boost库名称（比如date_time库）。
- 然后是编译器的版本，与库名称之间以"-"而不是下划线"_"分隔（比如 -vc120）。
- 有“mt”的为“threading=multi”版本，没有的则是“threading=single”版本。
- 有“s”的为“runtime-link=static”版本，没有的则是“runtime-link=shared”版本。
- 有“gd”的为debug版本，没有的则是release版本。
- 所有的库都含有boost库的版本号结尾（比如1_56，其中的"."以下划线"_"代替）
（8）link, runtime-link 组合分析
假设一个库A依赖于库B，我们自己的程序client依赖于库A，即：
那么，link指的是client->A，runtime-link指的是A -> B
| link,与runtime-link的不同设置 | 连接过程分析 | 运行过程需要的文件 |
| link=static runtime-link=static |
client通过A.a (A.lib)静态包含A； A通过B.a (B.lib)静态包含B； 不关 .so .dll的事（这是动态库） |
client （源文件） 因为静态lib，已经在编译时候 加载到应用程序中了 |
| （默认方式） link=static runtime-link=shared |
client通过A.a (A.lib)静态包含A； 在运行时，client要动态调用B.so (B.dll) （动态加载运行时库） |
client B.so (B.dll) （源文件，与c/c++动态运行库） |
| link=shared runtime-link=shared |
client会包含A.a (A.lib)； A会包含 B.a (B.lib)； 但都只保存动态库的真正实现的stub， 运行时通过stub去动态加载 A.so (A.dll), B.so (B.dll) 中的实现 |
client A.so (A.dll) B.so (B.dll) （源文件，bootst的动态库，c/c++的动态库） |
| link=shared runtime-link=static |
没有这种使用方式 |
综上：在根据boost的源码编译boost的何种库时，最好采用默认的形式:
b2 stage --toolset=msvc-12.0 --stagedir="E:\boost_1_56_0_bin_SDK\msvc12" link=staticruntime-link=sharedthreading=multi debug release
至此，Boost的源码编译完毕！！！
编译后的Boost 特定类型的库将会在E:\boost_1_56_0_bin_SDK\msvc12目录下产生lib的文件夹，然后在此文件夹下面产生debug，以及release两个版本的库文件。
如下图：
配置VS2013编译器，然后使用开发boost应用
主要的配置两个：
包含头文件的Include路径：E:\boost_1_56_0
包含库文件的链接路径：E:\boost_1_56_0_bin_SDK\msvc12_release\lib