我在最新版本的OS X（即10.11 El Capitan）下使用Python的python.org框架版本。我需要构建一些依赖于最新版本编译器的扩展（例如，C ++ - 11特性）。然而，python.org python也可以在旧系统上运行，以实现向后兼容。
因此，它具有环境变量int。这意味着默认情况下会使用工具链构建扩展程序，我认为这些工具链会模仿MACOSX_DEPLOYMENT_TARGET=10.6，特别是在搜索gcc-4.2时。
过去，我已经通过安装更新的自制程序编译器并在安装前明确设置stdlib，CC等来修复此问题。
但是，我尝试过设置CXX，这似乎有效。这样安全吗？有什么缺点吗？ （我不需要分发这些版本，只需在本地使用它们吗？）
答案 0 :(得分：5)
为最近的Python版本构建的python.org OS X 64位/ 32位框架是在MACOSX_DEPLOYMENT_TARGET设置为10.6的基础上构建的，并在Mac OS X 10.6上构建，以确保与各种OS X的兼容性版本。目前该范围从10.6 Snow Leopard到10.11 El Capitan。使用Python的内置Distutils或使用Distutils的高级工具（例如pip）构建C或C ++扩展模块时，默认情况下，编译和链接环境的部署目标设置为解释器构建，在这种情况下10.6，尝试生成扩展模块，这些扩展模块将与解释器构建本身一样使用相同范围的OS X版本。很少需要改变这一点，因为Apple通常非常擅长维护Python本身使用的系统库和框架的向后兼容性。但是，如您所发现的，您可以通过在构建扩展模块之前设置MACOSX_DEPLOYMENT_TARGET环境变量来将部署目标覆盖到较新的版本。 （Distutils检查并且不允许将部署目标设置为比用于解释器构建的版本更早版本。）Distutils还通过设置相应的＆＃34;标准＆＃来尊重覆盖其他各种构建值。 34;环境变量，例如CC，CXX，CFLAGS，LDSHARED等。
如果您正在处理C ++代码，可能需要更改部署目标的一种情况。正如其他地方广泛讨论的那样，在最近的版本中，Apple一直在从基于GCC的libstdc++迁移到C ++程序的Clang / LLVM libc++标准库。 Apple一直在发货。 Python解释器及其提供的标准库根本不使用C ++，因此这个问题不会影响Python本身。但是，如果您使用用C ++编写的扩展模块（或链接到用C ++编写的第三方库），无论是您自己的还是第三方软件包（例如从PyPI下载），您可以< / em>需要注意的是，所有C ++代码都是使用相同的C ++标准库构建的，否则，不同的C ++模块不会共享对象。我没有这种C ++情况的个人经验，因此我不确定避免可能出现的任何问题的最佳方法是什么。但是，快速而肮脏的检查可能是在所有扩展模块上使用Apple的otool命令行实用程序，以及它们链接的共享库和框架，以查找对libstdc++和libc++的所有引用find -E . -regex '(.*\.so)|(.*\.dylib)' -exec otool -L '{}' ';'
，所以从检查输出开始：
not exists