奇怪的Python编译结果与“ - 启用共享”旗 [英] Strange Python compilation results with "--enable-shared" flag

问题描述

我正在使用Debian（它附带Python-2.7.3），试图从源代码编译Python-2.7.6，与Apache一起使用mod_wsgi。

显然，根据众多的答案，您必须使用 - 在编译mod_wsgi使用情况下使用--enable-shared。

执行以下步骤：

  ./ configure --enable-shared --prefix = / usr / local / bin / python-2.7.6 
 make 
 make install 
  

然后检查交互式shell @

/ usr / local / bin / python-2.7.6 / bin / python

我接受了Python 2.7.3（默认，2013年1月2日，14:09： 21）etc

为什么会导致Python 2.7.3？

我尝试使用可执行文件这是结果：

  linux-vdso.so.1 => （0x00007fff271ff000）
 libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0（0x00007f1545638000）
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0（0x00007f154541c000）
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2（0x00007f1545217000）
 libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1（0x00007f1545014000）
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6（0x00007f1544d92000）
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6（0x00007f1544a06000）
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1（0x00007f15447ef000）
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1（0x00007f15445d9000）
 /lib64/ld-linux-x86-64.so.2（0x00007f1545b40000）
  

如何阻止它使用系统库，而不是使用本地编译的版本？

我知道，只要恢复使用系统安装的Python版本，并且现实世界的差异为零，这将会更容易。但是这个行为似乎很奇怪。

解决方案

当你做Python的时候，运行它：

  LD_RUN_PATH = / usr / local / lib make 
  

设置环境变量LD_RUN_PATH强制'python'可执行文件生成以查找/ usr / local / lib之前/ usr / lib for Python共享库。

这在mod_wsgi文档中提到。

• http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library

在再次执行此操作之前，请确保您做了一个make distclean并重新运行配置，以确保您没有旧的构建产品。

I am using Debian (which comes with Python-2.7.3), trying to compile Python-2.7.6 from source for use with mod_wsgi alongside Apache.

Apparently you must use --enable-shared when compiling for mod_wsgi usage, according to numerous answers.

Following these steps:

./configure --enable-shared --prefix=/usr/local/bin/python-2.7.6
make
make install

And then checking the interactive shell @

/usr/local/bin/python-2.7.6/bin/python

I am greeted with "Python 2.7.3 (default, Jan 2 2013, 14:09:21)" etc

Why is it resulting in Python 2.7.3?

I tried ldd against the executable and this is the result:

linux-vdso.so.1 =>  (0x00007fff271ff000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f1545638000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f154541c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1545217000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f1545014000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1544d92000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1544a06000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f15447ef000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f15445d9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1545b40000)

How do I stop it from using the system library and instead use the locally compiled version?

I know that it is a lot easier for me to just revert to using the system installed Python version, and that the real-world difference is zero. But this behaviour seems strange.

解决方案

When you do the make of Python, run it as:

LD_RUN_PATH=/usr/local/lib make

Setting the environment variable LD_RUN_PATH forces 'python' executable generated to look in /usr/local/lib before /usr/lib for Python shared library.

This is mentioned in the mod_wsgi documentation.

• http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library

Before doing this again, make sure you do a 'make distclean' and rerun configure to make sure you haven't got old build products around.

这篇关于奇怪的Python编译结果与“ - 启用共享”旗的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！