# std.zig.system: improve native glibc version detection · gitcafe/zig

[View on GitCafe](https://git.cafe/gitcafe/zig/commit/5d1aab72d92d0ab512464af0d3ffc036467ac011)

Repository: [gitcafe/zig](https://git.cafe/gitcafe/zig)

Visibility: public

Requested revision: 5d1aab72d92d0ab512464af0d3ffc036467ac011

Requested commit: 5d1aab72d92d0ab512464af0d3ffc036467ac011

Commit: 5d1aab72d92d0ab512464af0d3ffc036467ac011

Tree: ee6af9d8d7f8d4a49bbb8cc2ed7b0c2af0f33469

Author: Andrew Kelley

Committer: Andrew Kelley

## Message

```
std.zig.system: improve native glibc version detection

When the Zig compiler is statically linked, it inspects the
/usr/bin/env ELF file to determine the native glibc version, by checking
the DT_RUNPATH, and then calling readlink() on the libc.so file, because
typically the symlink will have e.g. libc-2.33.so in the name, revealing
the glibc version.

Fortunately, this information is also in readlink() of ld.so, which is
available as the "INTERP" file path. This commit looks for e.g.
`ld-2.33.so` on the symlink data for the dynamic linker.

In theory a more complete solution would also look at `/etc/ld.so.cache`
if necessary, and finally fall back to some hard coded paths, in order
to resolve the location of libc.so, in order to do this readlink() trick
on the resulting path. You can find that flow chart with `man ld.so`.
But I think this logic will be enough to get a correct answer in all real
world cases.

This has been tested on Debian Buster and glibc-based Void Linux.

Fixes #6469

```

## Parents

- [1442aa7dc039fd77c483862e37b099fe6d43f369](https://git.cafe/gitcafe/zig/commit/1442aa7dc039fd77c483862e37b099fe6d43f369?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zig/tree/5d1aab72d92d0ab512464af0d3ffc036467ac011?format=markdown)