В чем смысл этой ImportError при импорте сгенерированного Cython файла .so?

Я просматриваю документацию Cython и создаю каждое из примеров приложений. Я немного застрял в использовании библиотек C. После успешного создания файла .so и попытки импортировать его в файл python с именем test.py возникает следующая ошибка.

$ python3.2 test.py 
Traceback (most recent call last):
  File "test.py", line 12, in <module>
    from queue import Queue
ImportError: dlopen(/Users/jeremy/Development/labs/python/cython_lib_wrapper/queue.so, 2): Symbol not found: _queue_free
  Referenced from: /Users/jeremy/Development/labs/python/cython_lib_wrapper/queue.so
  Expected in: flat namespace
 in /Users/jeremy/Development/labs/python/cython_lib_wrapper/queue.so

Файл .so находится рядом с файлом test.py. Так что, похоже, его надо найти. На нем работает последняя версия Cython с Python 3.2 на OSX 10.6.

Любые идеи?

Изменить – добавить команду сборки и выходные данные

$ python3.2 setup.py build_ext --inplace
running build_ext
cythoning queue.pyx to queue.c
building 'queue' extension
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c queue.c -o build/temp.macosx-10.6-intel-3.2/queue.o
    queue.c: In function ‘__pyx_f_5queue_5Queue_append’:
    queue.c:627: warning: cast to pointer from integer of different size
    queue.c: In function ‘__pyx_f_5queue_5Queue_extend’:
    queue.c:740: warning: cast to pointer from integer of different size
    queue.c: In function ‘__pyx_f_5queue_5Queue_peek’:
    queue.c:813: warning: cast from pointer to integer of different size
    queue.c: In function ‘__pyx_f_5queue_5Queue_pop’:
    queue.c:965: warning: cast from pointer to integer of different size
    gcc-4.2 -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -isysroot /Developer/SDKs/MacOSX10.6.sdk -g build/temp.macosx-10.6-intel-3.2/queue.o -o 

Редактировать 2 — добавление запрошенной в комментарий команды "otool"

queue.so:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

Редактировать 3 – добавить вывод "nm"

U ___stack_chk_fail
U ___stack_chk_guard
U _queue_free
U _queue_is_empty
U _queue_new
U _queue_peek_head
U _queue_pop_head
U _queue_push_tail
U dyld_stub_binder

grep cmd выводит это:

(undefined) external _queue_free (dynamically looked up)

person JeremyFromEarth    schedule 15.08.2011    source источник
comment
Это похоже на проблему со связью. Не могли бы вы пересобрать и включить сюда как выходные данные сборки, так и команду, используемую для сборки?   -  person stderr    schedule 15.08.2011
comment
@Mike Steder Спасибо, что посмотрели это, я добавил команду сборки и вывод.   -  person JeremyFromEarth    schedule 16.08.2011
comment
Хорошо, не очень повезло с воспроизведением, так что давайте попробуем еще немного отладить. Попробуйте nm queue.so и посмотрите, что указано рядом с _queue_free. Также используйте otool -L queue.so и проверьте, чтобы увидеть DYLD_LIBRARY_PATH (echo $DYLD_LIBRARY_PATH).   -  person stderr    schedule 16.08.2011
comment
Есть ли что-то особенное, что я должен искать в команде nm? Вывод довольно длинный. Я добавил вывод otool к исходному вопросу.   -  person JeremyFromEarth    schedule 16.08.2011
comment
Возможно, это может быть связано с тем, что два файла calg находятся не в том месте? Я попытался поместить их в usr/include/calg и usr/lib/calg/, но это привело к сбою сборки. После этого я переместил их в папку проекта, и сборка заработала нормально. Также ( echo $DYLD_LIBRARY_PATH ) возвращает пустую строку   -  person JeremyFromEarth    schedule 16.08.2011
comment
Вы ищете _queue_free в выводе nm. Вы можете просто сделать что-то вроде nm -m queue.so | grep _queue_free. Вы хотите увидеть, как определяется этот символ.   -  person stderr    schedule 16.08.2011
comment
Хорошо, я добавил вывод. Вам подходит то, как я описал файловую структуру? Кстати, спасибо за всю вашу помощь.   -  person JeremyFromEarth    schedule 16.08.2011


Ответы (1)


РЕДАКТИРОВАТЬ:

Ах, вы не упомянули, что у вас есть зависимость от кода в libcalg. Этот материал необходимо скомпилировать и включить при сборке расширения.

Просто измените setup.py:

# setup.py
# ...
ext_modules = [Extension("queue", ["queue.pyx", "libcalg/queue.c"])]
# ...

Мы могли бы сделать шаг назад и посмотреть, сможете ли вы построить действительно простой пример:

Я пробовал следующее (3 файла, myext.pyx, test.py, setup.py), и, похоже, все работает нормально. Конечно, у меня OS X 10.7, так что это не совсем то же самое, что и ваша среда. Чтобы исключить различия, возможно, вы можете скопировать их и построить для проверки работоспособности.

Содержимое myext.pyx:

# myext.pyx
def square(x):
    return x * x

Содержимое test.py

# test.py
from myext import square
print "%d squared is %d"%(4, square(4))

Содержимое setup.py:

# setup.py
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext

ext_modules = [Extension("myext", ["myext.pyx"])]

setup(
  name = 'Hello world app',
  cmdclass = {'build_ext': build_ext},
  ext_modules = ext_modules
)

Я создаю каталог, содержащий эти 3 файла:

cython_test$ /usr/bin/python setup.py build_ext --inplace 
running build_ext
cythoning myext.pyx to myext.c
building 'myext' extension
creating build
creating build/temp.macosx-10.7-intel-2.7
llvm-gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c myext.c -o build/temp.macosx-10.7-intel-2.7/myext.o
llvm-gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -Wl,-F. -arch i386 -arch x86_64 build/temp.macosx-10.7-intel-2.7/myext.o -o /Users/steder/SO/cython_test/myext.so

cython_test$ python test.py
4 squared is 16:

Моя среда имеет аналогичный вывод otool, и DYLD_LIBRARY_PATH также не установлен, но nm -m показывает квадрат, как определено.

Конкретно:

00000000000011d0 (__DATA,__data) non-external ___pyx_k__square
00000000000011e0 (__DATA,__data) non-external ___pyx_mdef_5myext_square
0000000000001218 (__DATA,__bss) non-external ___pyx_n_s__square
0000000000000c80 (__TEXT,__text) non-external ___pyx_pf_5myext_square

Пожалуйста, попробуйте и посмотрите, что команда nm -m покажет в вашей среде.

person stderr    schedule 15.08.2011
comment
Я только что установил и построил это, и он отлично работает. Я вижу тот же результат, когда запускаю nm. Единственное, что мне пришлось изменить, это оператор печати, потому что я использую Python 3.2, и вы должны использовать скобки. - person JeremyFromEarth; 16.08.2011
comment
Интересно... К сожалению, я не знаю, чем отличается ваше расширение очереди. Можете ли вы поделиться кодом? - person stderr; 16.08.2011
comment
Я очень ценю вашу помощь! Исходные файлы находятся здесь: whiplax.com/cython_lib_wrapper.zip - person JeremyFromEarth; 16.08.2011
comment
СЛАДКИЙ! Хотел бы я дважды проголосовать за этот ответ. После выполнения инструкций в вашем редактировании все, кажется, работает. Какая битва. Спасибо! Просто для ясности: добавляя лишний libcalg/queue.c в этот список, мы говорим Cython скомпилировать файл c, прежде чем связать его с queue.pyx? - person JeremyFromEarth; 16.08.2011
comment
Верно, это все. Теперь он компилирует оба и связывает их вместе в окончательный файл *.so. - person stderr; 16.08.2011