Link Python to distro-independent libcrypt.so

[TimoWilken]

We use el7-built Python binaries on el9 as well, but there, only libcrypt.so.2 is available (as opposed to libcrypt.so.1 on el7). However, loading .so.2 runtime still works, so patchelf the python executable to refer to the generic unversioned library.

@zensanp Is there some way you could test this? You can build the package as we do in the nightly builds using aliBuild build -a slc7_x86-64 --docker-image registry.cern.ch/alisw/slc7-builder:patchelf Python (the regular build container doesn't yet have patchelf).

[TimoWilken]

Hi @ktf, I've tried various ways to avoid having to patch the binary after compilation, but none have worked for me:

1. Static linking: this would require users to install the glibc-static system package on slc7 (or equivalent package elsewhere). This package is not present by default.
2. Forcing the linker to use the unversioned libcrypt.so, not libcrypt.so.1: this doesn't seem to be possible as far as I can tell; apparently GNU ld still resolves symlinks and will link to libcrypt.so.1 even when -l:libcrypt.so is given instead of -lcrypt.

I can't see a way around the patching-after-compilation approach unfortunately.

[ktf]

How difficult it is to bring in our own libcrypto?

[TimoWilken]

It's libcrypt (from glibc), not libcrypto (from openssl) in this case. I'm not sure compiling our own glibc is a good idea, but we might be able to use libxcrypt instead (which apparently Gentoo use as well). I don't know if this would cause any compatibility/interop problems with the host system (e.g. if we link against system libs that were linked against glibc's libcrypt), but the libxcrypt compatibility notes sound promising:

On Linux-based systems, by default libxcrypt will be binary backward compatible with the libcrypt.so.1 shipped as part of the GNU C Library. This means that all existing binary executables linked against glibc’s libcrypt should work unmodified with this library’s libcrypt.so.1.

However, the converse is not true: programs linked against libxcrypt will not work with glibc’s libcrypt. Also, programs that use certain legacy APIs supplied by glibc’s libcrypt (encrypt, encrypt_r, setkey, setkey_r, and fcrypt) cannot be compiled against libxcrypt.