В течение некоторого времени установщики python.org OS X были собраны с требованием предоставить один исполняемый файл Python и общую библиотеку, которая будет работать во всех последних выпусках OS X, поддерживающих процессоры PPC и Intel. Отдельное, но тесно связанное требование заключается в том, что конечные пользователи должны иметь возможность создавать и устанавливать пакеты Python с модулями расширения C или C ++. Еще одна цель - упростить с помощью таких инструментов, как py2app, создание и упаковку полноценных автономных приложений OS X, которые могут работать сразу после нескольких выпусков ОС. По разным причинам gcc-4.0 на OS X в настоящее время является единственной версией, которая отвечает всем этим требованиям. Но выбор цели развертывания ABI, архитектур сборки и OS X SDK также важны. Выбор среды сборки, которая позволяет самому Python (традиционный cPython) быть собран на любой поддерживаемой платформе, также помогает гарантировать, что модули расширения C могут быть собраны на любой из этих платформ.
Подробная информация: gcc-4.0 остается самой последней версией gcc, предоставленной в последних выпусках Developer Tools для 10.4. Средства разработки 10.5 и 10.6 предоставляют версии 4.0 и 4.2, но для 10.5 по-прежнему используется версия 4.0. Таким образом, gcc-4.0 является общим знаменателем для трех последних выпусков OS X. Помимо самой версии gcc, существует также вопрос о том, для чего нужно создавать ABI, то есть то, что OS X называет цель развертывания . Как правило, OS X делает все возможное, чтобы обеспечить обратную совместимость, позволяя старым двоичным файлам работать на более новых системах, даже если большинство из них динамически связаны. Таким образом, чтобы иметь возможность построить интерпретатор Python, который будет работать с 10.4 по 10.6, вы должны использовать gcc-4.0, установить MACOSX_DEPLOYMENT_TARGET на 10.4 (минимальный уровень OS X, необходимый для запуска), использовать соответствующий SDK для 10.4 (это несколько озадачивающе называется 10.4u, как в universal, и является необязательной установкой для 10.6 версий Xcode Developer Tools) и устанавливает универсальные архитектуры на i386 и ppc, единственные две из которых полностью поддерживается во время выполнения на всех этих системах.
Установщик OS X немного строит читы и делает еще один шаг вперед: они фактически устанавливают цель развертывания 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 10.3.9 проходит минимальное тестирование и тестирование в рамках процесса выпуска python.org, так что будьте осторожны.)
Gotchas : самое важное должно быть ясно из вышесказанного. При сборке или установке пакетов с модулями расширения убедитесь, что вы используете совместимую версию GCC, архитектуры, цель развертывания и SDK. К счастью, если пакет использует Python Distutils для сборки и установки модуля расширения, в общем, все это будет выполнено автоматически, поскольку Distutils использует сохраненные значения, основанные на среде сборки интерпретатора Python. Он охватывает практически все пакеты Python, которые поставляются с установочным скриптом setup.py, и применяется к инструментам установки более высокого уровня, которые используют Distutils под крышками, например, easy_install и pip.
Важное исключение: автоматическая установка Distutils GCC для gcc-4.0 - это то, что было добавлено после выпуска 10.6, сделало его проблемой, поэтому это не было сделано в более ранних выпусках 2.6 или 3.1 и вовсе не было в 2.5. Если есть сомнения, вы всегда можете установить и экспортировать его вручную, как показано в вашем вопросе.
Еще одна распространенная ошибка при сборке или установке модулей расширения возникает, когда модуль использует другие сторонние библиотеки или двоичные файлы. Они также должны быть совместимы. В частности, для 10.6 по умолчанию система строит, связывает и выполняет как Intel-64 (-arch x86_64), где это возможно. Это может привести к проблеме, заключающейся в том, что сторонние не-Python библиотеки, которые вы устанавливаете, не могут быть статически или динамически связаны с модулем расширения Python, потому что нет совместимой общей архитектуры (так как Python.org включает только 32-битную *) 1034 * и ppc арок). Чтобы обойти это, вы должны быть осторожны, чтобы создавать правильные универсальные архитектуры при создании сторонних библиотек. Насколько это легко сделать, сильно различается в разных библиотеках. Планируется, что в следующих выпусках Python 2.7 и Python 3.2 будет предусмотрен второй вариант 32-разрядной / 64-разрядной универсальной программы установки только для Intel, созданный для версий 10.6 и выше, который должен значительно облегчить жизнь в 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, такого как сборка и установка Python из MacPorts.