Это вопрос для начинающих и последующее описание этого, где я указал на GLPK.
Я пытаюсь получить PyGLPK, привязку Python для GNU Linear Programming Kit, но независимо от того, что я делаю, я не могу построить и установить GLPK, чтобы Python нашел это правильно. Это происходит после запуска. /configure, make и sudo make install в библиотеках GLPK и следуя инструкциям для PyGLPK.
В частности, вот ошибка, которую я получаю:
>>> import glpk
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site- packages/glpk.so, 2): Symbol not found: __glp_lpx_print_ips
Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/glpk.so
Expected in: dynamic lookup
Я предполагаю, что что-то не связано с чем-то еще и что оно, вероятно, имеет какое-то отношение к путям и переменным среды. Однако здесь, где мои способности в оболочке терпят неудачу, и я в недоумении, что делать дальше.
Редактирование
Я могу запустить GLPK Solver (glpsol
) из командной строки, поэтому я знаю, что он работает, по крайней мере теоретически.
В какой-то момент я попытался использовать MacPorts для установки версии GLPK. С тех пор я удалил эту версию, хотя и использовал MacPorts.
Здесь результат использования otool -L
, который, по-видимому, является ответом OS X на ldd
:
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/glpk.so:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.11)
Опять же, возможно, есть простой ответ на этот вопрос, но мне не повезло с Google, используя терминологию, которую я знаю.
Решила проблему!
Первое предложение Thomas Wouter было самым близким к знаку: модуль glpk.so
вообще не был связан с библиотекой C. Причина заключалась в том, что make
построил оригинальные библиотеки GLPK с помощью gcc4.2
и указав 64-битную архитектуру, тогда как модуль Python distutils
настаивал на создании исходного кода PyGLPK с помощью gcc-4.0
с 32-разрядной архитектурой.
Так как я не мог понять, как добавить флаги компилятора в distutils
, я просто перестроил библиотеки GLPK, форсируя флаги компилятора distutils
. Это было то, что в конечном итоге сработало.
Это, похоже, проблема с OS X 10.6. ./configure
скрипты запрашивают системную архитектуру, которая по умолчанию, по-моему, составляет x86_64
, хотя Python 2.6 лучше всего работает с 32-битными двоичными файлами.
Проблема не очень специфична для Python. Модуль glpk
- это модуль расширения, C-библиотека, которую загружает Python. Эта общая библиотека C имеет зависимость от библиотеки GLPK C, которую она обертывает; загрузка модуля расширения должна загружать библиотеку GLPK C, чтобы модуль расширения мог ссылаться на символы из библиотеки GLPK C, например __glp_lpx_print_ips
. По-видимому, что-то не удается. Это может быть одна из нескольких вещей:
Модуль расширения glpk.so
не может быть связан с библиотекой GLPK C вообще. Это означало бы, что он был построен без аргумента -l
, необходимого для связи с библиотекой GLPK, что означает, что проблема заключается в процедуре сборки модуля расширения glpk
. Вы можете определить, зависит ли glpk.so
от библиотеки C с помощью инструмента ldd
. Например:
% ldd /usr/lib/python2.6/lib-dynload/gdbm.so
linux-gate.so.1 => (0xb77bb000)
libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7799000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7780000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7639000)
/lib/ld-linux.so.2 (0xb77bc000)
Это показывает, что мой модуль расширения gdbm
связан с общей библиотекой libgdbm
(а также с другими разделяемыми библиотеками).
Модуль расширения glpk.so
может быть связан с библиотекой GLPK C правильно, но динамический компоновщик может оказаться не в состоянии найти библиотеку C. Обычно это вызывает другое предупреждение (о невозможности найти библиотеку C), но это может не произойти в MacOS. Вы можете увидеть это снова, используя инструмент ldd
: он будет перечислять зависимость, но не фактический загруженный файл (вместо этого он будет "не найден".)
Это обычно вызвано не установкой библиотеки C, или установкой ее где-то, что динамический компоновщик не знает, чтобы посмотреть. К сожалению, я не знаю, как MacOS X выполняет поиск в библиотеке, и как вы должны изменять пути, которые он сканирует. (В большинстве систем UNIX вы должны отредактировать /etc/ld.so.conf
или файл в /etc/ld.so.conf.d/
или запустите ldconfig -m
.)
Модуль расширения glpk.so
может быть связан правильно, и динамический компоновщик может правильно найти модуль, но модуль расширения GLPK может не определять этот символ в конце концов. Это может быть ошибкой в GLPK, или это может быть связано с тем, что динамический компоновщик находит другую библиотеку GLPK C (другую версию или другую, которая построена по-разному), или это может быть потому, что библиотека GLPK C была скомпилирована иначе, чем glpk.so
модуль расширения был. Это немного сложно диагностировать, хотя это значит, что нужно копать в фактические символы библиотеки C и файлы заголовков, используемые во время компиляции.
Я бы предположил, что все рассмотрено, проблема №2. Это наиболее распространенная проблема, особенно при установке в /usr/local
, что обычно означает ./configure
без аргумента --prefix
.
glpsol
работает, означает, что можно правильно связать библиотеку GLPK C. Это может означать, что этот инструмент связан статически, или он может быть скомпилирован с явным RPATH (путь поиска библиотеки времени выполнения), или он может быть скомпилирован с другими аргументами. Вы все еще должны выяснить, чем он отличается от того, как был построен модуль расширенияglpk.so