<p>这个问题并不是Python特有的。<code>glpk</code>模块是一个扩展模块,是Python加载的C共享库。这个C共享库依赖于它包装的glpkc库;加载扩展模块应该加载glpkc库,这样扩展模块就可以引用glpkc库中的符号,比如<code>__glp_lpx_print_ips</code>。很明显,有些东西失败了。可能是以下几种情况之一:</p>
<ol>
<li><p><code>glpk.so</code>扩展模块可能根本没有链接到glpkc库。这意味着它是在没有链接GLPK库所必需的<code>-l</code>参数的情况下构建的,这意味着问题出在<code>glpk</code>扩展模块的构建过程中。您可以使用<code>ldd</code>工具来判断<code>glpk.so</code>是否依赖于C库。例如:</p>
<pre><code>% 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)
</code></pre>
<p>这显示了我的<code>gdbm</code>扩展模块与<code>libgdbm</code>共享库(以及其他共享库)相链接。</p></li>
<li><p><code>glpk.so</code>扩展模块可能与GLPK C库正确链接,但动态链接器可能无法找到C库。通常这会产生一个不同的警告(关于找不到C库),但这可能不会发生在MacOS上。您可以再次使用<code>ldd</code>工具来看到这一点:它将列出依赖关系,而不是加载的实际文件(它将显示“notfound”)</p>
<p>这通常是由于没有安装C库,或是将其安装到动态链接器不知道要查找的地方而导致的。不幸的是,我不知道MacOSX如何进行库查找,以及如何修改它扫描的路径。(在大多数UNIX系统上,您可以编辑<code>/etc/ld.so.conf</code>或<code>/etc/ld.so.conf.d/</code>中的文件,或者运行<code>ldconfig -m</code>。)</p></li>
<li><p><code>glpk.so</code>扩展模块可能链接正确,动态链接器可能会正确找到该模块,但GLPK扩展模块可能终究不会定义此符号。这可能是GLPK中的一个bug,也可能是因为动态链接器发现了一个<em>不同的</em>GLPK C库(不同的版本,或者构建方式不同),也可能是因为GLPK C库的编译方式与<code>glpk.so</code>扩展模块的编译方式不同。不过,这有点难以诊断,因为这意味着要深入研究实际的C库符号和编译过程中使用的头文件。</p></li>
</ol>
<p>我想,综合考虑,问题是2。这是最常见的问题,尤其是在<code>/usr/local</code>中安装时,这正是没有<code> prefix</code>参数的<code>./configure</code>通常要做的事情。在</p>