This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: "--enable-shared" during configure forces "2.7.3" to build as "2.7.2+" on Ubuntu 11.10
Type: Stage: resolved
Components: Installation Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: ikeaxial, ned.deily
Priority: normal Keywords:

Created on 2013-01-07 06:29 by ikeaxial, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg179247 - (view) Author: Isaac (.ike) Levy (ikeaxial) Date: 2013-01-07 06:29
Host OS: Ubuntu 11.10 (oneiric)
--enable-shared flag during configure forces 2.7.3 to build as 2.7.2+

TO REPLICATE:

unpack Python tarball,

# cd Python-2.7.3/
# ./configure --enable-shared
# make
# ./python -V
2.7.2+

# make clean ; ./configure --enable-shared ; make ; ./python -V
2.7.3


--
Additionally, 2.7.2+ build seems to carry over a resolved urandom issue,

    # (post-install on Ubuntu 11.10)
    # /usr/local/bin/python
    Python 2.7.2+ (default, Oct  4 2011, 20:41:12)
    [GCC 4.6.1] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from os import urandom
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: cannot import name urandom
    >>>
msg179251 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2013-01-07 09:14
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.
msg179259 - (view) Author: Isaac (.ike) Levy (ikeaxial) Date: 2013-01-07 12:20
Ned, absolutely correct, thank you!
History
Date User Action Args
2022-04-11 14:57:40adminsetgithub: 61087
2013-01-07 12:20:26ikeaxialsetmessages: + msg179259
2013-01-07 09:14:47ned.deilysetstatus: open -> closed

type: compile error ->

nosy: + ned.deily
messages: + msg179251
resolution: not a bug
stage: resolved
2013-01-07 06:29:16ikeaxialcreate