Skip to main content
Unix & Linux

Return to Answer

show LD_RUN_PATH and patchelf examples
Source Link
thrig
thrig
  • 35.8k
  • 4
  • 70
  • 88

Time to runThis is completely undocumented in the python 2.7.13 straceREADME I guessfile, but one can use LD_* tricks (or ELF-mangling applications, below) to see whyworkaround this deficiency of the python build is sucking so hardprocess. Also! If possible avoid building to the default of /usr/local as that will mix whatever version you're building into whatever might be in /usr/local; GNU stow or similar could be used if you do need a /usr/local/bin/python program but want the actual build sequestered off in, say, /usr/local/python-2.7.13:

-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
-bash-4.2$ make && sudo make install
...

Ugh, the LD_RUN_PATH method requires two builds, and now the second (the first build installed 2.7.13 libpython2.7 libraries this next build picks up on and uses)...

-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
...
-bash-4.2$ LD_RUN_PATH=/usr/local/python-2.7.13/lib make
...
-bash-4.2$ ldd ./python
    linux-vdso.so.1 =>  (0x00007ffca7bcd000)
    libpython2.7.so.1.0 => /usr/local/python-2.7.13/lib/libpython2.7.so.1.0 (0x00007fc6534fb000)
...
-bash-4.2$ sudo make install
...
-bash-4.2$ /usr/local/python-2.7.13/bin/python --version
Python 2.7.13
-bash-4.2$

With instead ELF-mangling tools, one of which is https://github.com/NixOS/patchelf which after being installed per the README file in that repository one can do a single python build and install:

-bash-4.2$ sudo rm -rf /usr/local/python-2.7.13
-bash-4.2$  ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
-bash-4.2$ make
-bash-4.2$ patchelf --set-rpath /usr/local/python-2.7.13/lib python
-bash-4.2$ sudo make install
-bash-4.2$ ldd /usr/local/python-2.7.13/bin/python
    linux-vdso.so.1 =>  (0x00007ffeb57ac000)
    libpython2.7.so.1.0 => /usr/local/python-2.7.13/lib/libpython2.7.so.1.0 (0x00007fcea6b75000)
...
-bash-4.2$ /usr/local/python-2.7.13/bin/python --version
Python 2.7.13
-bash-4.2$

Time to run strace I guess to see why the python build is sucking so hard...

This is completely undocumented in the python 2.7.13 README file, but one can use LD_* tricks (or ELF-mangling applications, below) to workaround this deficiency of the python build process. Also! If possible avoid building to the default of /usr/local as that will mix whatever version you're building into whatever might be in /usr/local; GNU stow or similar could be used if you do need a /usr/local/bin/python program but want the actual build sequestered off in, say, /usr/local/python-2.7.13:

-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
-bash-4.2$ make && sudo make install
...

Ugh, the LD_RUN_PATH method requires two builds, and now the second (the first build installed 2.7.13 libpython2.7 libraries this next build picks up on and uses)...

-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
...
-bash-4.2$ LD_RUN_PATH=/usr/local/python-2.7.13/lib make
...
-bash-4.2$ ldd ./python
    linux-vdso.so.1 =>  (0x00007ffca7bcd000)
    libpython2.7.so.1.0 => /usr/local/python-2.7.13/lib/libpython2.7.so.1.0 (0x00007fc6534fb000)
...
-bash-4.2$ sudo make install
...
-bash-4.2$ /usr/local/python-2.7.13/bin/python --version
Python 2.7.13
-bash-4.2$

With instead ELF-mangling tools, one of which is https://github.com/NixOS/patchelf which after being installed per the README file in that repository one can do a single python build and install:

-bash-4.2$ sudo rm -rf /usr/local/python-2.7.13
-bash-4.2$  ./configure --enable-shared --with-ensurepip --prefix=/usr/local/python-2.7.13
-bash-4.2$ make
-bash-4.2$ patchelf --set-rpath /usr/local/python-2.7.13/lib python
-bash-4.2$ sudo make install
-bash-4.2$ ldd /usr/local/python-2.7.13/bin/python
    linux-vdso.so.1 =>  (0x00007ffeb57ac000)
    libpython2.7.so.1.0 => /usr/local/python-2.7.13/lib/libpython2.7.so.1.0 (0x00007fcea6b75000)
...
-bash-4.2$ /usr/local/python-2.7.13/bin/python --version
Python 2.7.13
-bash-4.2$
Source Link
thrig
thrig
  • 35.8k
  • 4
  • 70
  • 88

I...what the...anyways, this also happens on Centos 7 which is more or less RHEL which is more or less Oracle linux. Notably if we run ldd on the resultant binary

-bash-4.2$ ldd ./python
    linux-vdso.so.1 =>  (0x00007ffdb238e000)
    libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007fc691bfe000)
...

the build of 2.7.13 has for some reason picked up on the system-wide /lib64/libpython2.7* library, version 2.7.5. Without --enabled-shared the version is correctly 2.7.13:

-bash-4.2$ make distclean
...
-bash-4.2$ ./configure --disable-shared --with-ensurepip && make
...
-bash-4.2$ ldd ./python
    linux-vdso.so.1 =>  (0x00007ffffab95000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f59a15a2000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f59a139e000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00007f59a119a000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f59a0e98000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f59a0ad7000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f59a17d0000)
-bash-4.2$ ./python --version
Python 2.7.13
-bash-4.2$

Time to run strace I guess to see why the python build is sucking so hard...