You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Build *-unknown-linux-gnu binaries with old glibc for portability #12005
We should prioritize shipping binaries that actually run on supported platforms, which we cannot guarantee if they’re linked against a newer glibc than the target system provides.
For example, such binaries may fail on Ubuntu 22.04, which remains under standard support until April 2027.
Perhaps we should consider discontinuing the GNU-linked binaries entirely. Users who specifically need them can install them through their package manager or build from source.
latest-commit is coming from same CICD.yml workflow. So nothing we should especially care about it (though release build for all unmerged PRs is overkill for me).
I also don’t think we want *-unknown-linux-gnu binaries to effectively require glibc 2.43 once ubuntu-latest on GitHub-hosted runners moves to 26.04, so we should address this before that happens.
We currently run GnuTests with release-small profile. If we used outdated Ubuntu at there and publish binaries, it is 0 cost.
Also GNU has some unshare tests masking /proc.
Strongly disagree for performance. We already have musl binary. Please close this issue soon.
@sylvestre Compatibility should take priority over performance, since GNU parity is the goal? We should check whether GNU coreutils 9.11 is compatible with older glibc versions.
Separately, I think we should make sure that binaries built against an older glibc pass tests.
I think this is important for alignment with the project’s design goals. If GNU Coreutils can be built and used with an older glibc, then uutils should aim to support that as well.
I'm not happy with encouraging people to hesttate updating to newer secure Linux.
I don't think that's relevant here. A distribution that is still within its vendor's support lifecycle should be considered a supported and secure target, even if it ships an older glibc.
Outdated distributions have a bunch of downstream patches. It is impossible to support all of them. Supporting legacy Ubuntu because Ubuntu is the most famous is unfair (but I have no fair solution yet).
I think targeting the previous Ubuntu LTS release is a reasonable compromise for now. Supporting much older systems all the way back to glibc 2.17 (e.g. RHEL 7) would likely require significantly more effort.
Longer term, the more robust solution would be to use cross to build the Linux binaries against an older Linux distribution running in Docker, which allows compatibility with a much wider range of systems.
I think making sure that binaries built against an older glibc pass tests is reasonable and consistent with the project design goals. I believe #12292 is a reasonable compromise.
Ah, I see the misunderstanding now. I assumed it was generally understood that, thanks to glibc's backward compatibility guarantees, binaries built against an older version of glibc will run on systems with newer versions. So my understanding is that targeting an older glibc broadens compatibility rather than dropping support for newer systems.
It is ideally true, but not true. ~stty was broken when glibc changed baudrate constants. It was broken just bumping system glibc.~ It seems const is determined at build time, but ignoring newer glibc is still invalid as we need to catch regression with stty linked against newer glibc.
~stty was broken when glibc changed baudrate constants.
I'm not sure, but it seems like that issue was incorrect error handling in the nix crate, not a glibc backwards compatibility issue.
My point is that glibc provides strong backwards compatibility guarantees, but cannot do anything for forwards compatibility. So while linking against an older glibc is always safe with respect to newer systems, linking Rust binaries against newer versions of glibc can break on newer systems and cause Undefined Behavior.
It immediately causes symbol error. So people can switch to musl soon. No need to downgrade glibc.
stty issue is not nix's bug. It is glibc itself's issue which should be catched by the CI.
Related: The test case gnu-stty 51; uu-stty panic (or simply stty 51 in the future) has strong dependency for GNU linked against newer glibc because it is available only with newer glibc. So if we pinned glibc, it actually blocks one of a compatibility too.
Activity
oech3 commentedon Apr 26, 2026
Strongly disagree for performance. We already have musl binary. Please close this issue soon.
oech3 commentedon Apr 26, 2026
But I'm OK to include output of
libc.so.6 --version | head -n 1.xtqqczze commentedon Apr 26, 2026
We should prioritize shipping binaries that actually run on supported platforms, which we cannot guarantee if they’re linked against a newer glibc than the target system provides.
For example, such binaries may fail on Ubuntu 22.04, which remains under standard support until April 2027.
oech3 commentedon Apr 26, 2026
xtqqczze commentedon Apr 26, 2026
Perhaps we should consider discontinuing the GNU-linked binaries entirely. Users who specifically need them can install them through their package manager or build from source.
oech3 commentedon Apr 26, 2026
Unfortunately, static musl binary cannot support stdbuf. So we cannot reduce to one target.
xtqqczze commentedon Apr 26, 2026
We also have latest-commit binaries.
oech3 commentedon Apr 26, 2026
latest-commit is coming from same
CICD.ymlworkflow. So nothing we should especially care about it (though release build for all unmerged PRs is overkill for me).xtqqczze commentedon Apr 26, 2026
I also don’t think we want
*-unknown-linux-gnubinaries to effectively require glibc 2.43 onceubuntu-lateston GitHub-hosted runners moves to 26.04, so we should address this before that happens.oech3 commentedon Apr 26, 2026
We should fix (lib)stdbuf instead of dropping glibc version.oech3 commentedon Apr 26, 2026
Oh, I was missing that there is nothing we can LD_PRELOAD to musl binary. So actually nothing to fix.
oech3 commentedon Apr 26, 2026
In my opinion, people want to use latest
stdbufshould use latest Ubuntu LTS too. Also I don't think may people are interested instdbuf.oech3 commentedon May 1, 2026
We currently run GnuTests with
release-smallprofile. If we used outdated Ubuntu at there and publish binaries, it is 0 cost.Also GNU has some
unsharetests masking/proc.xtqqczze commentedon May 14, 2026
@sylvestre Compatibility should take priority over performance, since GNU parity is the goal? We should check whether GNU coreutils 9.11 is compatible with older glibc versions.
oech3 commentedon May 14, 2026
I say again, We are already distributing musl binary.
20 remaining items
xtqqczze commentedon May 30, 2026
I think this is important for alignment with the project’s design goals. If GNU Coreutils can be built and used with an older glibc, then uutils should aim to support that as well.
oech3 commentedon May 30, 2026
Reuse https://github.com/uutils/coreutils/blob/main/.devcontainer/Dockerfile if it is needed. I'm not happy with encouraging people to hesttate updating to newer secure Linux.
xtqqczze commentedon May 30, 2026
I don't think that's relevant here. A distribution that is still within its vendor's support lifecycle should be considered a supported and secure target, even if it ships an older glibc.
oech3 commentedon May 30, 2026
Outdated distributions have a bunch of downstream patches. It is impossible to support all of them. Supporting legacy Ubuntu because Ubuntu is the most famous is unfair (but I have no fair solution yet).
xtqqczze commentedon May 30, 2026
I think targeting the previous Ubuntu LTS release is a reasonable compromise for now. Supporting much older systems all the way back to glibc 2.17 (e.g. RHEL 7) would likely require significantly more effort.
Longer term, the more robust solution would be to use cross to build the Linux binaries against an older Linux distribution running in Docker, which allows compatibility with a much wider range of systems.
oech3 commentedon May 30, 2026
We should just wait actual consumer's complaint and see response for suggestion to use musl binary. No need to add something without actual usecase.
xtqqczze commentedon May 30, 2026
I think making sure that binaries built against an older glibc pass tests is reasonable and consistent with the project design goals. I believe #12292 is a reasonable compromise.
oech3 commentedon May 30, 2026
xtqqczze commentedon May 30, 2026
Ah, I see the misunderstanding now. I assumed it was generally understood that, thanks to glibc's backward compatibility guarantees, binaries built against an older version of glibc will run on systems with newer versions. So my understanding is that targeting an older glibc broadens compatibility rather than dropping support for newer systems.
You can read more about backward compatibility here: https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility
oech3 commentedon May 30, 2026
oech3 commentedon May 30, 2026
And since musl is compatible with everything, it should not hurt to restrict glibc to latest.
xtqqczze commentedon May 30, 2026
I'm not sure, but it seems like that issue was incorrect error handling in the
nixcrate, not aglibcbackwards compatibility issue.My point is that
glibcprovides strong backwards compatibility guarantees, but cannot do anything for forwards compatibility. So while linking against an olderglibcis always safe with respect to newer systems, linking Rust binaries against newer versions of glibc can break on newer systems and cause Undefined Behavior.oech3 commentedon May 31, 2026
oech3 commentedon May 31, 2026
Related: The test case
gnu-stty 51; uu-sttypanic (or simply stty 51 in the future) has strong dependency for GNU linked against newer glibc because it is available only with newer glibc. So if we pinned glibc, it actually blocks one of a compatibility too.