我想将当前项目移至C ++ 11。代码全部使用clang ++ -std = c ++ 0x编译。这是容易的部分:-)。困难的部分是处理外部图书馆。人们不能依赖于将一个C ++ 11对象与未使用c ++ 11编译的外部库相链接（参见http://gcc.gnu.org/wiki/Cxx11AbiCompatibility）。例如，Boost肯定需要重建（Why can't clang with libc++ in c++0x mode link this boost::program_options example?）。我有我使用的所有外部库的源代码，所以我可以（有些痛苦）从理论上用C ++ 11重新构建这些库。但是，这仍然给我带来了一些问题：
在混合C ++ 03 / C ++ 11环境中开发：我有一些使用C ++ 03的旧项目，需要偶尔进行维护。当然，我想将这些与现有版本的外部库链接起来。但是对于我当前（和新）的项目，我想链接到我重新构建的C ++ 11版本的库。如何组织我的开发环境（目前是Ubuntu 12.04和Mac OS X 10.7）来应对这种情况？
我假设很多开发人员都会遇到这个问题。它不会消失，但我没有找到推荐的，普遍认可的解决方案。
部署：目前，我部署到云中的Ubuntu 12.04 LTS服务器。经验导致一个人（在可能的情况下）依赖于linux发行版提供的标准包（例如libboost）。如果我将当前项目移动到c ++ 11，我的理解是我将不得不构建自己的外部库版本。我的猜测是，在某些时候这将改变，并且它们将是具有C ++ 11兼容性的库标准的“标准”版本。当有人预料到会发生这种情况时，有谁有任何想法？并且可能这也需要上述问题的标准解决方案 - 在同一平台上同时存在C ++ 03库和C ++ 11库。
我希望我错过了一些基本的东西，以便这些感知的问题在适当的信息中消失！我是否想过早地转向C ++ 11？
更新（2013-09-11）：macports的相关讨论：https://lists.macosforge.org/pipermail/macports-users/2013-September/033383.html
答案 0 :(得分：1)
您应该使用配置工具链（例如autotools）“正确”配置目标部署的构建。您的配置测试应检查ABI兼容的C ++ 11二进制文件，并指示链接器在检测到时首先使用它们。如果没有，可选失败或回退到C ++ 03版本。
对于安装在单独的并行目录树中的C ++ 11第三方库，这不是绝对必要的。库版本已经存在了很长时间，允许您在系统或任何地方并排放置不同的版本，再次基于configure。
这可能看起来很乱，但配置工具链是为处理这些混乱而设计的。