由于要跑出代码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