virtual_specs glibc

[drewgilliam]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

The GLIBC version check introduced in #809 doesn't seem to be appropriate for alpine images with GLIBC installed.

#809 introduced virtual_specs to fail quickly if installed dependencies are not appropriate. The GLIBC check for alpine systems is here, given by

# musl ldd will report musl version; call ld.so directly
system_glibc_version=$($(find /lib/ /lib64/ -name 'ld-linux-*.so*' 2>/dev/null | head -1) --version | awk 'NR==1{ sub(/\.$/, ""); print $NF}')

This fails for an alpine image with GLIBC installed such as the following docker

FROM docker:20.10.16

RUN apk del libc6-compat; \
    apk --no-cache add ca-certificates curl findutils; \
    curl -fsSLo /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub; \
    curl -fsSLo /tmp/glibc.apk https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.28-r0/glibc-2.28-r0.apk; \
    apk add /tmp/glibc.apk;

RUN LD_SO=$(find /lib/ /lib64/ -name 'ld-linux-*.so*' 2>/dev/null | head -1); \
    ${LD_SO} --version

The final line of the docker, mimicking the GLIBC test of virtual_specs, fails with the following error

--version: error while loading shared libraries: --version: cannot open shared object file

Is there a more appropriate test for the GLIBC version in an alpine docker?

Thanks in advance for any help!

Additional Context

No response

[jaimergp]

Hm, that looks like we couldn't find the .so in those directories. I'll check your reproducer and report back.

[jaimergp]

Turns out that this ld.so doesn't implement --version or --help or anything that would report the version of GLIBC. I haven't found a way to find this (easily or at all) in this particular Docker image. If you come up with more or less simple way of checking it (e.g. no compilation steps, just CLI calls), then we can look into a adding it to the existing checks.

/ # /lib64/ld-linux-x86-64.so.2 --version
--version: error while loading shared libraries: --version: cannot open shared object file
/ # /lib64/ld-linux-x86-64.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file.  This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it.  You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run.  This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.

  --list                list all dependencies and how they are resolved
  --verify              verify that given object really is a dynamically linked
                        object we can handle
  --inhibit-cache       Do not use /usr/glibc-compat/etc/ld.so.cache
  --library-path PATH   use given PATH instead of content of the environment
                        variable LD_LIBRARY_PATH
  --inhibit-rpath LIST  ignore RUNPATH and RPATH information in object names
                        in LIST
  --audit LIST          use objects named in LIST as auditors

[drewgilliam]

@jaimergp - looks like libc.so.6 reports the GLIBC version

/ # /usr/glibc-compat/lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.28.
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 5.4.0 20160609.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Maybe first look for libc.so.6 in standard locations, then if not found query /etc/ld.so.cache?

LIBC_SO="$(find /lib /usr/local/lib /usr/lib -name 'libc.so.6' -print -quit)"
if [ -z "${LIBC_SO}" ]; then LIBC_SO="$(strings /etc/ld.so.cache | grep '^/.*/libc.so.6' | head -1)"; fi

https://sourceware.org/glibc/wiki/FAQ#:~:text=If%20you%20want%20to%20find,%24%20%2Flib%2Flibc.

[jaimergp]

We merged #856 now, so I think this can be closed. Want to give main a try @drewgilliam?