use RHEL 7 / CentOs 7 as the baseline glibc version rather than oldest Debian under LTS

[markus-oberhumer]

Zig Version

0.9.0

Steps to Reproduce

Commit 1530203 changed the default glibc cross-compile version to 2.19 which is incompatible with RHEL 7 / CentOs 7 which use glibc 2.17. RHEL 7 will be supported until Jun 2024 (and even until Jun 2026 with commercial ELS).

I'm not sure if there are technical reasons for this change and reverting to 2.17 might be worthwhile.

In any case a new -zig-target-glibc might solve issues like these in the future (related to #4911).

[marler8997]

I think this is the syntax you would need to select glibc 2.17:

zig cc --target=native-linux-gnu.2.17 ...

[markus-oberhumer]

@marler8997 Many thanks for that hint, I only had tried --target=x86_64-linux-gnu-2.17.

[andrewrk]

@markus-oberhumer I changed the title of the issue to reflect the fact that this is merely a question of the baseline glibc version. Check out the commit message of 1530203. If you would like to see this proposal accepted, please make a case here for why to prefer RHEL over Debian as the reference point.

[markus-oberhumer]

I'd suggest that the generic linux-gnu name should target the oldest supported and still widely used Linux LTS distribution (Debian/RHEL/Suse/Ubuntu). For x86_64 I think this is RHEL 7 with glibc 2.17 at the moment.

Unless, of course, there are technical reasons to prefer a newer glibc by default.

Please feel free to close this issue if you disagree.

[marler8997]

How feasible would it be to automatically select the oldest version of glibc to link against based on the symbols being used? Since glibc is backwards-compatible, this would mean programs linked with the Zig toolchain would work on the most systems possible by default. This would give Zig another leg up on the GNU toolchain because the best solution they have for this is to find an old image with an old version of glibc and complile their software with that image. Not only is this quite cumbersome, it also means version selection is a manual process. Being able to programmatically determine the oldest compatible version could turn some heads...By default Zig binaries will work on as many platforms as possible based on the API being used.

[markus-oberhumer]

See also rust-lang/compiler-team#493 where Rust only recently changed its minimum requirements from kernel 2.6.32/glibc 2.11 to kernel 3.2/glibc 2.17.

[markus-oberhumer]

Rust Blog: Increasing the glibc and Linux kernel requirements

https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html

[motiejus]

How feasible would it be to automatically select the oldest version of glibc to link against based on the symbols being used?

Sometimes glibc has multiple implementations of the same symbol under different versions. E.g.:

$ readelf -Ws /lib/x86_64-linux-gnu/libc.so.6 | grep pthread_attr_getaffinity_np
  2244: 0000000000092200   174 FUNC    GLOBAL DEFAULT   15 pthread_attr_getaffinity_np@GLIBC_2.3.4
  2245: 00000000000922b0    17 FUNC    GLOBAL DEFAULT   15 pthread_attr_getaffinity_np@GLIBC_2.3.3
  2246: 0000000000092200   174 FUNC    GLOBAL DEFAULT   15 pthread_attr_getaffinity_np@@GLIBC_2.34

You can see more symbols with more than one implementation:

$ readelf -Ws /lib/x86_64-linux-gnu/libc.so.6 | awk '/@/{print $8}' | sed 's/@.*//' | uniq -c | sort -rn | grep -vw 1

Usually newer ones are "better", but old ones still work. If we take the defaults only (in this case, GLIBC_2.34, since it has @@), we may have a binary that ... does not even run on the current system.

Pick the oldest that still works with the system's glibc? In that case Zig can link to the system's glibc in the first place. :)

[markus-oberhumer]

This issue is a request to set the default glibc target to 2.17 instead of 2.19 to make all binaries compatible with RHEL 7 by default.

Rationale:

• https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html

• Increase the minimum linux-gnu versions rust-lang/compiler-team#493

Is has nothing to do with the installed system library.

[daurnimator]

I thought we originally picked the oldest supported release by any major distro, and Debian just happened to have the oldest at the time.
i.e. oldest glibc in use out of a non-EOL RHEL/non-EOL Debian/non-EOL Suse, etc.

[markus-oberhumer]

Closing after more than one year.