Новое в Python: GLPK не собирается должным образом / Python ImportError

Question

Это вопрос для начинающих, и продолжение на этот , где мне указали на 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

Я предполагаю, что что-то не связано с чем-то другим, и что это, вероятно, связано с путями и переменными среды. Однако, вот где мои способности в оболочке не работают, и я в недоумении, что делать дальше.

Правки

1. Я могу запустить GLPK Solver (glpsol) из командной строки, поэтому я знаю, что он работает, по крайней мере, в теории.

2. В какой-то момент я попытался использовать MacPorts для установки версии GLPK. С тех пор я удалил эту версию, хотя и с использованием MacPorts.

3. Вот результат использования 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, используя терминологию, которую я знаю.

Answer 1

Решил проблему!

Первое предложение Томаса Воутера было ближе всего к цели: модуль glpk.so вообще не был связан с библиотекой Си. Причина была в том, что 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-битными двоичными файлами.

Answer 2

Проблема не совсем специфична для Python. Модуль glpk является модулем расширения, разделяемой библиотекой C, которую загружает Python. Эта совместно используемая библиотека C зависит от библиотеки GLPK C, которую она упаковывает; загрузка модуля расширения должна загрузить библиотеку GLPK C, чтобы модуль расширения мог ссылаться на символы из библиотеки GLPK C, например __glp_lpx_print_ips. Видимо, что-то там не получается. Это может быть одна из нескольких вещей:

1. Модуль расширения 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 (а также с другими общими библиотеками).

2. Модуль расширения glpk.so может быть правильно связан с библиотекой C GLPK, но динамический компоновщик может не найти библиотеку C. Обычно это выдает другое предупреждение (о невозможности найти библиотеку C), но это может не произойти в MacOS. Вы можете убедиться в этом снова, используя инструмент ldd: в нем будет отображена зависимость, но не фактический загруженный файл (вместо этого будет указано «не найден».)

   Обычно это вызвано не установкой библиотеки C или установкой ее где-то, что динамический компоновщик не знает, где искать. К сожалению, я не знаю, как MacOS X выполняет поиск в своей библиотеке и как вы должны изменять сканируемые пути. (В большинстве систем UNIX вы бы отредактировали /etc/ld.so.conf или файл в /etc/ld.so.conf.d/ или запустили ldconfig -m.)

3. Модуль расширения glpk.so может быть правильно связан, и динамический компоновщик может найти модуль правильно, но модуль расширения GLPK может не определять этот символ в конце концов. Это может быть ошибкой в ​​GLPK, или это может быть потому, что динамический компоновщик находит другую библиотеку GLPK C (другую версию или ту, которая построена по-другому), или это может быть потому, что GLPK C библиотека была скомпилирована иначе, чем модуль расширения glpk.so. Однако это немного сложно диагностировать, поскольку это означает копание в реальных символах библиотеки C и файлах заголовков, используемых во время компиляции.

Я думаю, что, учитывая все обстоятельства, проблема №2. Это самая распространенная проблема, особенно при установке в /usr/local, что обычно делает ./configure без аргумента --prefix.