search

indygreg / python-build-standalone

Produce redistributable builds of Python
BSD 3-Clause "New" or "Revised" License
1.75k stars 109 forks source link

Link against an older `glibc` ABI #74

Closed cipriancraciun closed 3 years ago

cipriancraciun commented 3 years ago

Currently if I try to run the build for Python 3.9.1 (from January 3rd 2021, as found in the releases of this repository) on OpenSUSE Leap 15.2 (the latest up-to-date stable release for OpenSUSE) I get an error regarding the fact that the OpenSUSE glibc is too old for the current Python build:

/lib64/libc.so.6: version `GLIBC_2.32' not found

(Apparently the glibc is at version 2.26 on OpenSUSE Leap 15.2. As side-note, the same build has no problem running on the latest OpenSUSE Tumbleweed that uses 2.33.)

This could be solved by running the build on an older Linux (for example a CentOS 6) which could provide a good-enough base-line and thus be forward compatible with many current distributions.

(Perhaps it is even possible that during the Python build, one can specify the maximum glibc ABI version to link against.)

indygreg commented 3 years ago

The build is performed in a Debian Jessie environment with glibc 2.19. And the Rust verification code cracks open the ELF and verifies that glibc symbol versions aren't greater than 2.17 (nothing in the build appears to use new glibc symbols from 2.18 or 2.19).

I'm really curious how the reference to a GLIBC_2.32 symbol is getting in there. Are you linking anything on your end or are you using the pre-built executables in the python/install directory?

If you could help provide more context on where that symbol is coming from, it would be greatly appreciated. grepping readelf -a /path/to/binary output for GLIBC_2.32 might give us some answers.

cipriancraciun commented 3 years ago

Sorry, my mistake... The Python interpreter works as expected...

The issue was from a custom Rust launcher that I used to launch your Python interpreter, due to the fact that if one symlinks the python executable itself somewhere, and calls it as such, then it fails to find it's lib folder.

I do this because I need to install Python in a relocable folder, and then somehow symlink the interpreter in a folder that is part of $PATH. My launcher just uses /proc/self/exec to find itself regardless on how it is invoked and then launches the actual python executable.