Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 3.8, 3.9, and 3.10 link libcrypt.so.1 unexpectedy in releases 20230726 and later #197

Closed
rmartin16 opened this issue Nov 23, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@rmartin16
Copy link

With closure of #173 via a1e4e44, the releases were only expected to link libcrypt.so.1 from the _crypt so.

For Python 3.11 and 3.12, this is the case; however, Python 3.8, 3.9, and 3.10 still seem to link libcrypt.so.1 elsewhere.

For instance, if we consider cpython-3.10.13+20231002-x86_64-unknown-linux-gnu-install_only.tar.gz:

ldd ~/Downloads/cpython-3.10.13+20231002-x86_64-unknown-linux-gnu-install_only/python/lib/libpython3.so 
	linux-vdso.so.1 (0x00007ffceffa8000)
	/home/user/Downloads/cpython-3.10.13+20231002-x86_64-unknown-linux-gnu-install_only/python/lib/../lib/libpython3.10.so.1.0 (0x00007f1dcb600000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1dccb2b000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f1dcb41e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f1dccb26000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f1dcb33d000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f1dccb1f000)
	libcrypt.so.1 => not found
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f1dccb1a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1dccb4b000)

And if we consider cpython-3.11.6+20231002-x86_64-unknown-linux-gnu-install_only.tar.gz:

ldd ~/Downloads/cpython-3.11.6+20231002-x86_64-unknown-linux-gnu-install_only/python/lib/libpython3.so 
	linux-vdso.so.1 (0x00007ffe85306000)
	/home/user/Downloads/cpython-3.11.6+20231002-x86_64-unknown-linux-gnu-install_only/python/lib/../lib/libpython3.11.so.1.0 (0x00007fd922000000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd9237fb000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fd921e1e000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fd9237f6000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fd921d3d000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fd9237ef000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007fd9237ea000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd92381b000)

The same is also true of the Python binary. These tests were completed on Fedora 39; although, my current blocker is for recent Flatpak runtimes. I don't think this is a regression since a1e4e44; I had the same experience for 20230726 and 20230826.

Thank you for this work; it's greatly appreciated.

@indygreg
Copy link
Owner

Thanks for the report. Definitely unintended behavior.

This is on my backlog and I'll look at it the next time I sit down to hack on python-build-standalone. Probably not until late December at the earliest.

@indygreg
Copy link
Owner

indygreg commented Jan 7, 2024

I have a fix applied locally. Should push soon.

Turns out this was buggy behavior in CPython <3.11 configure script. See python/cpython#28881.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants