为什么python.org网站用gcc4.0构建的苹果操作系统安装程序？

Question

在回答SO question 3500638时，内德·戴利说苹果提供的Python（2.5.4和2.6.5）都是用gcc-4.2构建的。但是，这三个python.orgOSX python（2.6.5、2.7、3.1.2）都是使用gcc-4.0构建的。在

问题

1. 为什么python.orgPython（2.6.5，2.7，3.1.2）是用gcc-4.0构建的？在
2. 使用gcc-4.0构建的python.orgPython有什么窍门？在

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

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

Answer 1

根据Python issue 6957：

Recent python.org installers are built using the OS X 10.4 SDK so that one installer image will work on 10.4, 10.5 and now 10.6 (in theory, 10.3.x as well).

这就回答了为什么python.org网站Python使用gcc-4.0，我仍然有兴趣知道除了在构建Python扩展时必须设置gcc-4.0之外，是否还有其他问题。在

Answer 2

这可能与苹果提供的用于OSX10.5的Python（2.5.1）毕竟是用gcc-4.0构建的，python.org网站的DMG同时支持OSX10.5和10.6（不确定它们是否也支持旧版本的操作系统）。在

Answer 3

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

   血淋淋的细节：gcc-4.0仍然是最新的gcc版本，在10.4的最新版本中提供。10.5和10.6开发工具同时提供4.0和4.2，但4.0仍然是10.5的默认版本。因此，gcc-4.0是最近三个osx版本的共同点。除了gcc版本本身之外，还有一个问题是为哪个ABI构建，即OS X调用的部署目标。一般来说，OSX在确保向后兼容性方面做了一些努力，允许较旧的二进制文件在较新的系统上工作，即使大多数二进制文件是动态链接的。因此，为了能够构建一个在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和{}，这是所有这些系统在运行时完全支持的唯一两个。在

   OSX安装程序构建了一个有点作弊的地方，并且更进一步：他们实际上将部署目标设置为10.3，结果发现，这将产生一个二进制文件，该二进制文件将适用于所有的OS X版本，从10.6到OS X 10.3.9，最后的10.3版本，尽管不适用于早期的10.3版本。（注意，如果您仍在使用10.3.9，因为gcc-4.0不包含在10.3开发人员工具中，因此在那里构建C扩展模块可能需要手动干预，例如重写gcc版本，并且您可能会遇到其他问题。作为python.org网站这些天发布过程，所以用户要小心。）

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

   一个重要的例外：GCC的Distutils自动设置为GCC-4.0是在10.6版本之后添加的，因此在2.6或3.1的早期版本中没有这样做，在2.5中也没有。当您有疑问时，您始终可以手动设置并导出它，如您的问题所示。在

   当模块使用其他第三方库或二进制文件时，另一个在构建或安装扩展模块时遇到的常见问题。这些也必须兼容。尤其是对于10.6系统tem默认值是尽可能以Intel-64（-arch x86_64）的形式构建、链接和执行。这可能导致您安装的第三方非Python库不能静态或动态地与Python扩展模块链接，因为没有兼容的公共体系结构（因为python.org网站Python只包含32位的i386和ppcarch）。为了解决这个问题，在构建第三方库时，您需要小心地强制使用正确的通用体系结构。实现这一点的难易程度在不同的库中差别很大。计划在python2.7和python3.2的下一个版本中包含第二个32位/64位Intel通用安装程序选项，该选项为10.6及更高版本构建，这将使在64位系统上的工作更加轻松。（注意，对于2.7的初始版本，有第二个32位/64位安装程序，除了它是为10.5及更高版本构建的，并且还包括32位ppc。不幸的是，这个配置有很多问题，包括IDLE和{}不能在10.6上工作。我只会谨慎使用。）

   对于许多具有第三方库依赖关系的流行Python包（PIL和MySQLdb）来说，还有另一种方法可以最大限度地减少兼容性问题，它是使用第三方开放源码软件包分发服务器中的一个完整的解决方案（Python、Python包和第三方库），例如MacPorts、Homebrew或Fink。每种方法都有一些缺陷，但从长远来看，它们的使用通常可以避免很多麻烦。在

   显然，另一个问题是试图构建一个依赖于新特性或缺陷修复的包，而这个新特性或缺陷修复在苹果的gcc-4.0版本中没有找到。我不知道有这样的包裹，但可能有一些。如果是这样的话，这可能是另一个使用其他Python解决方案的好理由，比如从MacPorts构建和安装Python。