{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaqai4nwaeuuskha7zrnwzborhgx2hu2rkld77h4oq3a6p247ubdq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml7thvamu2o2"
  },
  "path": "/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225#post_11",
  "publishedAt": "2026-05-06T21:35:18.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "this workaround",
    "@GLIBC_2.X"
  ],
  "textContent": "zackw:\n\n> It is not even _remotely_ that simple. People keep thinking it's that simple because there are a bunch of cases where it'll work by accident, but usually when glibc adds a new version for one or more of its public symbols, it's because, at the assembly-language level, _you need to call the new version differently than the old one_. The difference is invisible at the C level, because the header files shipped with glibc-2.X tell the C compiler how to call all the `@GLIBC_2.X` symbols correctly. But rustc would have to know what the difference is, for every glibc symbol that has multiple versions, and that's a big reverse engineering job. Way too big, IMHO, to ask the rust team to take on all by themselves.\n\nI think you missed the point. This RFC would not prevent you from doing something like this workaround. Rust declares GLIBC 2.17 compatibility. This means that today, I can grab any distro with GLIBC 2.17, build my program there, and there will be no GLIBC functions in VERNEED that use GLIBC versions newer than 2.17. This is exactly why Rust docker images are based on quite old distros, why zig-build works (it just uses zig linker that fakes the libc symbols for the linker).\n\nToday, to produce a binary that works everywhere (meaning old distros with old GLIBC), I have the following options:\n\n  * Use that old distro as a build environment. Very Linux/GNU way, very unfriendly for any sort of commercial development, and just inconvenient for people who want to use modern tools in their work.\n  * Use zig cc + zig-build. Requires the Zig compiler, which has an unclear support status and can be challenging to justify for production environments.\n  * Use custom GCC/LLVM builds that link binaries against the required version of GLIBC (crosstool-ng, etc)\n  * Use cross, that is, in general a combination of the two above (can use zig or can use custom GCC toolchain)\n\n\n\nNone of the above removes the requirement for a developer to actually know what GLIBC function is called and make that decision consciously. All they do is either isolate the host glibc environment from the linker or just replace the host environment entirely. But all those workarounds are highly desirable for people who have to produce software that runs on multiple platforms and cannot be distributed only in source form (yes, commercial software exists).\n\nzackw:\n\n> I'd recommend you pursue the idea _through the glibc project_.\n\nI would not even bother reaching out to them. GLIBC position is clear - they only support a couple of recent versions and a couple of recent GCC releases. If you want to have GCC 16 that links against GLIBC 2.17, you are on your own. That burden rests on projects like crosstool-ng.\n\nzackw:\n\n> You shouldn't make up target tuple variations without coordination across the entire ecosystem of programs that use target tuples.\n\nThis is why we collect feedback, right? As I already said above, this is the zig-build-like way to specify the desired glibc (which, in its way, borrowed that from zig itself to specify the target). And if you read the RFC, the idea is that the suffix should be downgraded to `-C target-libc=glibc:X.Y` ASAP, since many internals rely on the exact triple name. Also, users are not required to use exactly this form if, say, external tools are breaking (and anyone using zig-build today with that form should already have handled it in their environments).\n\nAs I mentioned above - this suffix form was proposed exclusively to simplify migration from the existing zig-build-dependent project.",
  "title": "[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets"
}