為什么使用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。