我对是否链接 libboot_*-mt 变体以及它们的实际用途有点困惑。
我在 Centos 6 上使用 boost 1.46.0 的自定义反向移植。该构建生成 /usr/lib64/libboost_thread-mt.so.7 以及 -mt 和其他库的标准版本。
我编写了一个单元测试程序，它使用线程将计算存储在 boost::future 中。要链接该测试，我必须添加 -lboost_thread-mt。但是我不需要更改其他 boost -l args 来使用 -mt 版本。
我已经阅读了boost 站点上的Library Naming 部分，但我不清楚“表明该库是在启用多线程支持的情况下构建的。没有多线程支持的库可以通过缺少 -mt 来识别”实际上是什么意思。
如果我与 -lboost_thread-mt 链接，是否需要切换到其他库的多线程感知版本？如果没有，我什么时候需要链接 -mt 变体？
是否有建议仅在需要时才选择性地链接到 -mt 变体？该项目使用 GNU Make 进行构建。
总是链接到 -mt 变体是否有性能或功能损失？
当您threading=multi在 bjam 行中设置时，将构建“mt”变体。“mt”选项的后果之一BOOST_HAS_THREADS是定义。
当然，您链接的所有 boost 库都应该是相同的变体，这与您的应用程序的线程匹配。否则，您最终可能会违反 ODR：想象一个shared_ptr在没有 . 的库 A中编译BOOST_HAS_THREADS，而在没有 . 的库 B中编译BOOST_HAS_THREADS。两者shared_ptr的自旋锁类实现完全不同。因此，如果您shared_ptr从库 A 获取并将其传递给库 B，您的程序就会崩溃。此外，mt 和非 mt 变体可能使用不同的堆。
（也就是说，值得一提的是 BOOST_HAS_THREADS 依赖于其他一些宏，甚至可以在非 mt 变体中定义，因此将 mt 与非 mt 混合有时会起作用——但不要依赖于此。）
至于性能损失 - 显然，mt 变体可能会慢一些。
更新：我的假设BOOST_HAS_THREADS 似乎是错误的。尽管如此，混合 mt/非 mt 变体还是个坏主意，因为这threading=multi会影响 Boost ABI。