我对是否链接libboot _ * - mt变体以及它们实际用于什么感到困惑。
我在Centos 6上使用boost 1.46.0的自定义backport。构建产生/usr/lib64/libboost_thread-mt.so.7以及其他库的-mt和标准版本。
我编写了一个单元测试程序，它使用一个线程将计算存储在boost :: future中。要链接该测试，我必须添加-lboost_thread-mt。但是我不需要更改其他boost -l args来使用-mt版本。
我看过Library Naming 关于boost网站的部分，但我不清楚“表明该库是在启用了多线程支持的情况下构建的。没有多线程支持而构建的库可以通过缺少-mt来识别”实际意味着。
如果我与-lboost_thread-mt链接，是否需要切换到其他库的多线程感知版本？如果没有，我什么时候需要链接-mt变种？
是否建议仅在需要时才有选择地链接-mt变体？该项目使用GNU Make for builds。
始终链接-mt变种是否会产生性能或功能损失？
答案 0 :(得分：3)
在bjam行中设置threading=multi时会构建“mt”变体。 “mt”选项的后果之一是定义了BOOST_HAS_THREADS。
当然，你链接的所有boost库都是相同的变体，它与你的应用程序的线程相匹配。否则，您最终可能会遇到ODR违规行为：假设您在库A中编译shared_ptr而没有BOOST_HAS_THREADS，而库B编译BOOST_HAS_THREADS。两个shared_ptr具有完全不同的spinlock类实现。因此，如果从lib A获得shared_ptr并将其传递给lib B，则程序崩溃。此外，mt和非mt变体可能使用不同的堆。
（据说，值得一提的是BOOST_HAS_THREADS依赖于其他一些宏，甚至可以在非mt变体中定义，因此将mt与非mt混合可能偶尔会起作用 - 但不要依赖于此。 ）
至于性能损失 - 显然，mt变体可能会慢一些。
更新：我对BOOST_HAS_THREADS appears to be wrong的假设。但是，混合mt / non-mt变体是个坏主意，因为threading=multi会影响Boost ABI。