Ned Deily added the comment: You need to be careful when using a Python with --enable-shared to ensure that the correct dynamic libraries are being used at execution time. Normally, after a "make", you use "make install" to install the Python executable and the shared library into the configured locations, by default in /usr/local. If you try to run a --enable-shared python executable from its build directory, you'll need to tell the dynamic loader where to find the shared library, i.e. the build directory itself. One way to do that is to use the LD_LIBRARY_PATH environment variable. Otherwise, the dynamic loader will search the standard paths, like /usr/local/lib/ and /usr/lib/ for a shared library with the proper name (like libpython2.7.so.1.0). If there is an older Python already installed with that name and if the ABI hasn't changed too much, you may be lucky and it will load and run. In your example, you undoubtedly had a Python 2.7.2+ already installed in either /usr or /usr/local. In this example, I have a shared 2.7.3rc2 installed in /usr/bin and am building a 2.7.3:
$ ./configure --enable-shared ; make $ /usr/bin/python2.7 -V Python 2.7.3rc2 $ ./python -V Python 2.7.3rc2 $ LD_LIBRARY_PATH=. ./python -V Python 2.7.3 The "make clean" and rebuild step you show makes no difference by itself. Without installing or setting the library search path, the older installed library will still be picked up. What likely happened is that you did a "make install" in between the two steps. ---------- nosy: +ned.deily resolution: -> invalid stage: -> committed/rejected status: open -> closed type: compile error -> _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16883> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
