Skip to content

capture-libs: Don't treat libcrypt.so.1 as part of glibc

Simon McVittie requested to merge wip/task332 into master

  • capture-libs: Add references for some more architectures

    Just for completeness, we're not going to support any of these any time soon.

  • capture-libs: Add notes on which libraries are still part of glibc

  • library-cmp: Make some symbols static

    These are only directly used within their translation unit, therefore don't need to be extern.

  • capture-libs: Don't treat libcrypt.so.1 as part of glibc

    libcrypt.so.1 is build-time optional since glibc 2.28, and is not built by default since 2.38. In newer distributions like Debian >= 11 and Ubuntu >= 20.04, it's usually replaced by libxcrypt, either compiled to be a drop-in replacement for glibc's libcrypt.so.1 (as in Debian, and therefore the Steam Runtime), or with its own SONAME libcrypt.so.2 and optionally a secondary build as libcrypt.so.1 (as in Arch).

    Because libxcrypt implements a superset of the glibc libcrypt.so.1 ABI, adding some functions and symvers of its own, it is backward- but not forward-compatible: it's OK to use libxcrypt libcrypt.so.1 as a replacement for glibc libcrypt.so.1, but it is not OK to do the opposite. This means it would be incorrect for us to use a system copy of glibc libcrypt.so.1 (perhaps from glibc 2.32 or newer) as a replacement for a container's libxcrypt libcrypt.so.1, even if the system copy of glibc is strictly newer than the container's glibc (for example, Steam Runtime 3 'sniper' is based on Debian 11, so it comes with glibc 2.31 and libxcrypt).

    Unlike libpthread, libdl and librt, symbols from libcrypt.so.1 were never absorbed into libc.so.6, so we don't have to apply the reasoning seen in 4c2e3e3b "capture-libs: Add a special case to support glibc 2.34+".

    In practice we've always got away with it in the past, but it's something that could cause a crash or incompatibility. I'm now looking into the possibility of backporting libxcrypt into Steam Runtime 1 and 2 (steamrt/tasks#332), which makes it more important to get this right.

    Accordingly, exclude libcrypt.so.1 from that special treatment, and instead set it up to be compared separately using the same comparators we use for glibc: by public symvers, then by public symbols, and as a last resort by name.

See steamrt/tasks#332 for test results.

/cc @denittis @vivek

Edited by Simon McVittie

Merge request reports