1

这是一个初学者问题，也是这个问题的后续问题，我被指向 GLPK。

我正在尝试启动和运行PyGLPK ，这是一个用于GNU 线性编程工具包的 Python 绑定，但无论我做什么，我似乎都无法构建和安装 GLPK 以便 Python 正确找到它。这是在 GLPK 库上运行 ./configure、make 和 sudo make install 并遵循 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

我假设某些东西没有链接到其他地方，并且它可能与路径和环境变量有关。然而，这就是我在 shell 中的能力失败的地方，我不知道下一步该做什么。

编辑

  1. 我能够从命令行运行 GLPK Solver ( glpsol)，所以我知道它可以工作，至少在理论上是这样。

  2. 有一次，我尝试使用 MacPorts 安装 GLPK 版本。我已经卸载了这个版本，尽管使用的是 MacPorts。

  3. 这是 using 的结果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)

同样，这可能有一个简单的答案，但我对使用我知道的术语的谷歌没有任何运气。

4

2 回答 2

1

这个问题并不是真正特定于 Python 的。该glpk模块是一个扩展模块，一个 Python 加载的 C 共享库。该 C 共享库依赖于它所包装的 GLPK C 库；加载扩展模块应该加载 GLPK C 库，以便扩展模块可以引用 GLPK C 库中的符号，例如__glp_lpx_print_ips. 显然，有些事情失败了。它可能是以下几件事之一：

  1. glpk.so扩展模块可能根本没有链接到 GLPK C 库。这意味着它是在没有-l链接到 GLPK 库所需的参数的情况下构建的，这意味着问题出在glpk扩展模块的构建过程中。您可以glpk.so通过该ldd工具判断是否依赖于 C 库。例如：

    % 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 C库glpk.so，但动态链接器可能无法找到 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参数。

于 2010-04-28T11:27:58.373 回答
1

解决了问题！

Thomas Wouter 的第一个建议是最接近标记的：该glpk.so模块根本没有链接到 C 库。原因是使用并指定 64 位架构make构建原始 GLPK 库，而 Python 的模块坚持使用32 位架构构建 PyGLPK 的源代码。gcc4.2distutilsgcc-4.0

由于我不知道如何将编译器标志添加到distutils，我只是重建了强制distutils编译器标志的 GLPK 库。这就是最终奏效的方法。

这似乎是 OS X 10.6 的问题。./configure脚本查询系统架构，我认为默认情况下是x86_64，即使 Python 2.6 最适合 32 位二进制文​​件。

于 2010-05-03T08:27:11.883 回答