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

glibc check: alternatives to ldd needed #1439

Open
mistydemeo opened this issue Oct 3, 2024 · 7 comments
Open

glibc check: alternatives to ldd needed #1439

mistydemeo opened this issue Oct 3, 2024 · 7 comments

Comments

@mistydemeo
Copy link
Contributor

We use ldd to determine glibc's version. While this is commonly available, it may be missing on some minimal Linux distros. It would be good for us to provide fallbacks so we can still determine the glibc version.

This was reported via uv, where a user was using WolfiOS with no ldd by default: astral-sh/uv#7903

@duckinator
Copy link
Contributor

I have cursed knowledge relevant to your quest. 😄

Your best bet is probably ld.so --version. Yes, really.

Elaborating a bit:

  1. Technically, .so files are executable (although most don't expect to be executed directly and segfault if you try).
  2. Dynamically-linked ELF executables are "interpreted": a "program interpreter" sets the program and libraries up in memory then runs it.
  3. That program interpreter is ld.so, so it should afaik always be on any Linux system using ELF executables.
  4. You can just run it.
  5. It's in the PATH and marked executable.
  6. On GNU systems, it accepts a --version flag and prints glibc information.

Works on at least Debian and WolfiOS; not sure if it's 100% universal on glibc systems, so it might make sense to try both ld.so and ldd?

@duckinator
Copy link
Contributor

If a full path is needed, it seems to usually be /usr/lib/ld.so.

@duckinator
Copy link
Contributor

duckinator commented Oct 30, 2024

The information varies a bit by distro, but I think running ld.so --version and doing something like .split("\n").first().split(" ").last() and removing the trailing . will get you close.

Debian:

~$ ld.so --version
ld.so (Debian GLIBC 2.36-9+deb12u8) stable release version 2.36.

WolfiOS:

a0d24a0a7bb3:/# ld.so --version
ld.so (glibc-2.40-r3) stable release version 2.40.

Fedora:

[root@c49aa3e35d96 /]# ld.so --version
ld.so (GNU libc) stable release version 2.39.

ArchLinux:

[root@f1bda685b4ec /]# ld.so --version
ld.so (GNU libc) stable release version 2.38.

Alma Linux:

[root@499aadfe68e1 /]# ld.so --version
ld.so (GNU libc) stable release version 2.34.

@fasterthanlime
Copy link
Contributor

Note that we still want to run ldd at least on Alpine:

~ via 🐍 v3.9.6 took 15s
❯ docker run -it --rm alpine /bin/sh
/ # ld.so --version
/bin/sh: ld.so: not found
/ # ldd
musl libc (aarch64)
Version 1.2.5
Dynamic Program Loader
Usage: /lib/ld-musl-aarch64.so.1 [options] [--] pathname
/ #

(And presumably on other musl distros)

@mistydemeo
Copy link
Contributor Author

This issue's specifically about glibc - we're not doing dynamic musl builds/system musl version checking yet.

@fasterthanlime
Copy link
Contributor

we're not doing dynamic musl builds/system musl version checking yet.

got it!

though yet is load-bearing here because... musl target's eventually going to change (has been in the works since 2021), we're going to need to care about this at this point

@mistydemeo
Copy link
Contributor Author

Yes, agreed! We've been tracking that progress for sure. I just mean that it's not relevant to this issue - we'll want to do it when we start musl version tracking

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants