为什么使用gcc-4.0构建python.org OS X安装程序？

Question

在回答问题3500638时 ，Ned Deily表示Apple提供的Pythons（2.5.4和2.6.5）都是用gcc-4.2构建的。 但是，所有三个python.org OS X Pythons（ 2.6.5,2.7,3.1.2 ）都是使用gcc-4.0构建的。

问题

1. 为什么使用gcc-4.0构建python.org Pythons（ 2.6.5,2.7,3.1.2 ）？
2. 使用gcc-4.0构建的python.org pythons之一有什么问题？

至于第二个问题，我发现自己在构建Python扩展之前发出了以下一个或多个命令：

export CC=/usr/bin/gcc-4.0
export CPP=/usr/bin/cpp-4.0
export CXX=/usr/bin/g++-4.0

Answer 1

这可能与苹果提供的OS X 10.5的 Python（2.5.1）是用gcc-4.0构建的事实有关 - 毕竟，python.org的DMG支持OS X 10.5 和 10.6（不确定它们是否相同）也支持旧版本的操作系统）。

Answer 2

1. 一段时间以来，python.org OS X安装程序的构建需要提供一个Python可执行文件和共享库，这些库可以在支持PPC和Intel处理器的所有最新OS X版本上运行。 一个单独但密切相关的要求是，最终用户必须能够使用C或C ++扩展模块构建和安装Python包。 另一个目标是借助py2app等工具py2app构建和打包成熟的独立OS X应用程序，这些应用程序可以在多个操作系统版本上开箱即用。 由于各种原因，OS X上的gcc-4.0目前是满足所有这些要求的一个版本。 但是ABI部署目标，构建体​​系结构和OS X SDK的选择也是重要的问题。 选择允许在任何支持的平台上构建Python（传统的cPython）本身的构建环境也有助于确保可以在任何这些平台上构建C扩展模块。

   血腥细节：gcc-4.0仍然是最新的10.4版开发人员工具版本中提供的最新gcc版本。 10.5和10.6开发人员工具同时提供4.0和4.2，但4.0仍然是10.5的默认值。 因此，gcc-4.0是最新的三个OS X版本的共同点。 除了gcc版本本身之外，还有一个问题是要构建哪个ABI，即OS X称之为部署目标 。 通常，OS X会尽一切努力确保向后兼容性，允许较旧的二进制文件在较新的系统上工作，即使大多数动态链接也是如此。 因此，为了能够构建一个可以在10.4到10.6上工作的Python解释器，你可以使用gcc-4.0，将MACOSX_DEPLOYMENT_TARGET设置为10.4（运行所需的最低OS X级别），使用10.4的相应SDK（它有点令人困惑地称为10.4u ，与universal ，是Xcode开发人员工具的10.6版本的可选安装），并将通用架构设置为i386和ppc ，这是在所有这些系统上运行时完全支持的唯一两个。

   OS X安装程序稍微构建了一些欺骗行为并更进了一步：它们实际上将部署目标设置为10.3，结果表明，这将导致二进制文件适用于所有OS X版本，从10.6回到OS X 10.3 .9，最终的10.3版本，虽然不是早期的10.3版本。 （注意，如果您仍在使用10.3.9，因为10.3开发人员工具中不包含gcc-4.0，可能需要手动干预以在那里构建C扩展模块，例如覆盖gcc版本，并且您可能遇到其他问题。目前10.3.9上的Python作为python.org发布过程的一部分获得了最少的测试和曝光，因此用户要小心。）

2. 陷阱 ：最重要的应该从上面清楚。 在使用扩展模块构建或安装软件包时，请确保使用兼容的GCC版本，体系结构，部署目标和SDK。 幸运的是，如果软件包使用Python的Distutils来构建和安装扩展模块，通常所有这些都将自动处理，因为Distutils使用基于Python解释器构建环境的保存值。 这几乎涵盖了setup.py安装脚本附带的每个Python包，并适用于使用Distutils更高级别的安装工具，例如easy_install和pip 。

   一个重要的例外：由GCC的Distutils自动设置为gcc-4.0是在10.6发布之后添加的一个问题，因此它不是在早期版本的2.6或3.1中完成的，而在2.5中完全没有。 如有疑问，您可以随时设置并手动导出，如问题所示。

   当模块使用其他第三方库或二进制文件时，会出现构建或安装扩展模块时的另一个常见问题。 那些也必须兼容。 特别是，对于10.6，系统默认是在可能的情况下以Intel-64（ -arch x86_64 ）构建，链接和执行。 这可能导致您安装的第三方非Python库无法与Python扩展模块静态或动态链接的问题，因为没有兼容的通用体系结构（因为python.org Python仅包含32位i386和ppc archs）。 要解决这个问题，在构建第三方库时需要小心强制使用正确的通用体系结构。 这样做有多容易，各个库之间差异很大。 该计划适用于Python 2.7和Python 3.2的下一个版本，包括为10.6及更高版本构建的第二个32位/ 64位仅限Intel的通用安装程序选项，可以使64位系统的生活更加轻松。 （注意，对于2.7的初始版本，有第二个32位/ 64位安装程序，除了它是为10.5及更高版本构建的，并且还包括32位ppc。不幸的是，该配置结果是问题，包括IDLE和Tkinter在10.6上没有工作。我会谨慎使用它。）

   对于许多流行的具有第三方库依赖关系的Python包（ PIL和MySQLdb可以想到），还有另一种方法可以最大限度地减少兼容性问题，并且可以使用完整的解决方案（Python，Python包和第三方库）。 OS X的第三方开源软件包分销商之一，如MacPorts，Homebrew或Fink。 每一个都有一些陷阱开始，但从长远来看，它们的使用通常可以避免很多麻烦。

   显然，另一个问题是尝试构建一个依赖于Apple的gcc-4.0版本中没有的新功能或错误修复的软件包。 我不知道任何这样的包，但可能有一些。 如果是这样，这可能是另一个使用其他Python解决方案的好理由，例如从MacPorts构建和安装Python。

Answer 3

根据Python问题6957 ：

最近的python.org安装程序是使用OS X 10.4 SDK构建的，因此一个安装程序映像可以在10.4,10.5和现在10.6（理论上也是10.3.x）上运行。

虽然这解释了为什么python.org Pythons使用gcc-4.0，但我仍然有兴趣知道在构建Python扩展时是否还有任何问题需要设置gcc-4.0。