Python的新特性：GLPK没有正确构建/Python import

Question

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

我试图启动并运行PyGLPK，一个用于GNU Linear Programming Kit的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

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

编辑

1. 我能够从命令行运行GLPK解算器（glpsol），因此我知道它至少在理论上是可行的。

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

3. 下面是使用otool -L的结果，这显然是ldd的OS X答案：

   /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

解决了问题！在

thomaswouter的第一个建议最接近实际情况：glpk.so模块根本没有链接到C库。原因是make使用gcc4.2并指定一个64位体系结构来构建最初的GLPK库，而Python的distutils模块坚持使用32位体系结构的gcc-4.0构建PyGLPK的源代码。在

由于我无法确定如何向distutils添加编译器标志，所以我只是重新构建了GLPK库，强制使用distutils编译器标志。这就是最终奏效的方法。在

这似乎是OSX10.6的一个问题。./configure脚本查询系统架构，我认为默认情况下是x86_64，尽管python2.6最好使用32位二进制文件。在

Answer 2

这个问题并不是Python特有的。glpk模块是一个扩展模块，是Python加载的C共享库。这个C共享库依赖于它包装的glpkc库；加载扩展模块应该加载glpkc库，这样扩展模块就可以引用glpkc库中的符号，比如__glp_lpx_print_ips。很明显，有些东西失败了。可能是以下几种情况之一：

1. glpk.so扩展模块可能根本没有链接到glpkc库。这意味着它是在没有链接GLPK库所必需的-l参数的情况下构建的，这意味着问题出在glpk扩展模块的构建过程中。您可以使用ldd工具来判断glpk.so是否依赖于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.so扩展模块可能与GLPK C库正确链接，但动态链接器可能无法找到C库。通常这会产生一个不同的警告（关于找不到C库），但这可能不会发生在MacOS上。您可以再次使用ldd工具来看到这一点：它将列出依赖关系，而不是加载的实际文件（它将显示“notfound”）

   这通常是由于没有安装C库，或是将其安装到动态链接器不知道要查找的地方而导致的。不幸的是，我不知道MacOSX如何进行库查找，以及如何修改它扫描的路径。（在大多数UNIX系统上，您可以编辑/etc/ld.so.conf或/etc/ld.so.conf.d/中的文件，或者运行ldconfig -m。）

3. glpk.so扩展模块可能链接正确，动态链接器可能会正确找到该模块，但GLPK扩展模块可能终究不会定义此符号。这可能是GLPK中的一个bug，也可能是因为动态链接器发现了一个不同的GLPK C库（不同的版本，或者构建方式不同），也可能是因为GLPK C库的编译方式与glpk.so扩展模块的编译方式不同。不过，这有点难以诊断，因为这意味着要深入研究实际的C库符号和编译过程中使用的头文件。

我想，综合考虑，问题是2。这是最常见的问题，尤其是在/usr/local中安装时，这正是没有 prefix参数的./configure通常要做的事情。在