{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicrm47dzy6fjdauc25mrffihvnpuphfm5lrpci5kaphedmyqtbyhe",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml6ynj74nuq2"
  },
  "path": "/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225#post_8",
  "publishedAt": "2026-05-06T14:07:22.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Sovereign Tech Fund",
    "not a good use of their time",
    "@GLIBC_2.X"
  ],
  "textContent": "nikkon-dev:\n\n> Add first-class support to rustc and cargo for declaring a binary's glibc deployment target — the oldest glibc release the binary is required to run on.\n\nI support this idea in principle, but there's a major problem with it:\n\n> At build time, rustc synthesizes versioned glibc stub shared libraries containing only symbols introduced at or before the requested version, and points the linker at them; the resulting ELF's `VERNEED` entries cannot exceed the deployment target. The binary then loads on any host with that glibc version or newer.\n\nIt 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\nIf you're serious about this, I'd actually recommend you pursue the idea _through the glibc project_. Propose addition of a feature selection macro (`-D_GLIBC_DEPLOYMENT_TARGET=2.NN`) which, if you set it, you get machine code targeting that version of glibc -- as you say, works exactly the same way as `MACOSX_DEPLOYMENT_TARGET`. I think they'll be at least a _little_ receptive to the idea, although they will probably expect you to do all the work yourself and/or find a way to get people paid to do that work (e.g. a Sovereign Tech Fund grant)\n\nOnce that work is done, the `libc` crate will be able to expose it via cargo features, without needing to grovel through glibc's entire sources and change history to figure out what the actual difference between how you call `timer_create@GLIBC_2.3.3` and how you call `timer_create@GLIBC_2.34` is, multiply by 2,400 public symbols.\n\n* * *\n\nBesides that, a couple smaller notes:\n\n> Users opt in via either a target-tuple suffix (`--target x86_64-unknown-linux-gnu.2.28`)\n\nYou shouldn't make up target tuple variations without coordination across the entire ecosystem of programs that use target tuples.\n\nnikkon-dev:\n\n> This is written by me using AI tools based on the MVP implementation I tried. Actually, that was assisted with multiple AI models, agents, and tools.\n\nPlease don't do this anymore. Please don't use AI in _any way_ to \"help\" you write anything you want other people to read.\n\nFor a whole lot of reasons, but the most relevant one right now is that the overwhelming majority of people in this forum, and indeed the overwhelming majority of people working on open source software, are going to _stop reading_ and forget about your proposal the moment they realize they're reading something that wasn't written by a human. It's simply not a good use of their time.\n\nAnother very important reason for _this_ proposal is that I have seen several blog posts describing how to do the \"just call the old symbol\" that your AI-assisted MVP implementation does, without any awareness of what can go wrong. And that means what you have probably hits all the cases where \"just call the old symbol\" works by accident, and none of the ones where it'll appear to link correctly but then when you actually try to run the program it'll fail to load, crash, corrupt memory, or worse. And that, in turn, has led you to underestimate how much work it's going to be to implement your proposal _correctly_.\n\nOf course you might have made the same mistake if you'd set out to do the MVP entirely by hand, but there's a better chance that you would have noticed at least some of the problem cases.",
  "title": "[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets"
}