Создание модуля Python и соединение его против платформы MacOSX
Я пытаюсь создать расширение Python на MacOSX 10.6 и связать его против нескольких платформ (i386 только). Я сделал setup.py файл, с помощью distutils и Дополнительный объект.
Я заказываю для соединения против моих платформ, мой огибающий var LDFLAGS должен быть похожим:
LDFLAGS = -lc -arch i386 -framework fwk1 -framework fwk2
Поскольку я не нашел ключевого слова 'платформы' в Дополнительной документации модуля, я использовал extra_link_args ключевое слово вместо этого.
Extension('test',
define_macros = [('MAJOR_VERSION', '1'), ,('MINOR_VERSION', '0')],
include_dirs = ['/usr/local/include', 'include/', 'include/vitale'],
extra_link_args = ['-arch i386',
'-framework fwk1',
'-framework fwk2'],
sources = "testmodule.cpp",
language = 'c++' )
Все компилирует и связывается прекрасный. Если я удаляю - строка платформы от extra_link_args, моих сбоев компоновщика, как ожидалось. Вот последние две линии, продолженные Python setup.py сборка:
/usr/bin/g++-4.2 -arch x86_64 -arch i386 -isysroot /
-L/opt/local/lib -arch x86_64 -arch i386 -bundle
-undefined dynamic_lookup build/temp.macosx-10.6-intel-2.6/testmodule.o
-o build/lib.macosx-10.6-intel-2.6/test.so
-arch i386 -framework fwk1 -framework fwk2
К сожалению, .so, который я просто произвел, не может найти несколько символов обеспеченными этой платформой. Я пытался проверить связанную платформу с otool. Ни один из них не появляется.
$ otool -L test.so
test.so:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
Существует вывод otool, работает на тестовом двоичном файле, сделанном с g ++ и ldd использование LDFLAGS, описанного наверху моего сообщения. На этом примере - действительно работала платформа.
$ otool -L vitaosx
vitaosx:
/Library/Frameworks/fwk1.framework/Versions/A/fwk1 (compatibility version 1.0.0, current version 1.0.0)
/Library/Frameworks/fwk2.framework/Versions/A/fwk2 (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
Это может выйти быть связанным с "-неопределенный dynamic_lookup" флаг на связывающемся шаге? Я немного смущен несколькими строками документации, которую я нахожу на Google.
Удачи,
2 ответа
Похоже, что моя структура скомпилирована для ppc и i386, но не для x86_64:
$ file /Library/Frameworks/fwk1.framework/Versions/A/fwk1
/Library/Frameworks/fwk1.framework/Versions/A/fwk1: Mach-O universal binary with 2 architectures
/Library/Frameworks/fwk1.framework/Versions/A/fwk1 (for architecture ppc): Mach-O dynamically linked shared library ppc
/Library/Frameworks/fwk1.framework/Versions/A/fwk1 (for architecture i386): Mach-O dynamically linked shared library i386
Я удалил флаг -arch x86_64 из своей строки связывания. Моя библиотека связана с моими фреймворками:
$ otool -L test.so
test.so:
/Library/Frameworks/fwk1.framework/Versions/A/fwk1 (compatibility version 1.0.0, current version 1.0.0)
/Library/Frameworks/fwk2.framework/Versions/A/fwk2 (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
Если кто-то знает, как принудительно использовать -arch при компиляции и компоновке с distutils Python ... поделитесь, пожалуйста, своим советом.
Я не уверен, что понимаю, что вы пытаетесь сделать, и желаемый результат, но, возможно, это поможет. Поскольку модули расширения C обычно запускаются в контексте выполнения интерпретатора Python, модули расширения должны быть созданы для совместимости с интерпретатором. В OS X Python и distutils создают некоторые проблемы, чтобы гарантировать, что модули расширения C построены с одним и тем же SDK ( -sysroot ), значением MACOSX_DEPLOYMENT_TARGET и -arch , поскольку сам интерпретатор Python был изначально построен. Итак, если вы используете Python 10.6, distutils предоставит -arch i386 -arch ppc -arch x86_64 , три арки, с которыми он был построен. Если вы используете текущий установщик python.org OS X (на 10.6, 10.5 или 10.4), он будет использовать:
gcc-4.0 -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
Из предоставленных вами фрагментов я предполагаю, что вы используете универсальный Python, установленный MacPorts, и по умолчанию он построен с использованием -arch x86_64 -arch i386 -isysroot / для построения модулей расширения.
Как правило, чтобы все работало, вам необходимо убедиться:
в есть хотя бы одна
аркав , общая для интерпретатора, все модули расширения C , а также все внешние фреймворки и / или разделяемые библиотеки , которые они связывают с, которые интерпретатор выполняет в этой (или одной из этих) общей архитектуры (ах).
В OS X 10.6 этот последний шаг не так прост, как должен быть, в зависимости от того, какой Python вы используете. Например, Python 2.6, поставляемый Apple, имеет модификацию для принудительного выполнения 32-битного исполнения (подробнее см. Apple man python ):
export VERSIONER_PYTHON_PREFER_32_BIT=yes
Если вы создаете свой собственный 32- / 64-битный универсальный Python, в 2.6.5 есть исправления, позволяющие выбирать во время выполнения. К сожалению, способ, которым MacPorts создает Python, обходит эти исправления, поэтому не существует простого способа заставить 32- / 64-разрядную универсальную сборку MacPorts python2.6 на 10.6 работать в 32-разрядном режиме. По сложным причинам он всегда будет предпочитать 64-разрядную версию, если она доступна, даже если вы используете / usr / bin / arch -i386 .
Итак, в зависимости от того, что вы пытаетесь сделать, вы можете обойти проблему (если я правильно понимаю), либо:
- перестроив свои фреймворки, включив в него
-arch x86_64 - используйте поставляемый Apple Python (
/ usr / bin / python) в 32-битном режиме или python.org 2.6.5 переустановите Python MacPorts в 32-битном режиме (не проверено! ):
sudo port selfupdate sudo port clean python26 sudo port install python26 + universal universal_archs = i386