{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiawiimjimyz5sjdzvo2pqdvl5ixqp6gisflxxweqvcz7tkyrcmxkq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml5j2jmtjas2"
  },
  "path": "/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225#post_1",
  "publishedAt": "2026-05-06T00:57:19.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "cargo-zigbuild",
    "Rendered"
  ],
  "textContent": "## Summary\n\nAdd 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. Users opt in via either a target-tuple suffix (`--target x86_64-unknown-linux-gnu.2.28`), a Cargo config field (`[target.x86_64-unknown-linux-gnu] libc = \"2.28\"`), or a tracked codegen flag (`-C target-libc=glibc:2.28`). 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\nThis is exactly the shape of macOS `MACOSX_DEPLOYMENT_TARGET`: a single declared value with a build-time consequence (\"don't use APIs introduced after this release\") and a runtime consequence (\"requires at least this OS version installed\"). Today, accomplishing the same thing for glibc requires out-of-tree tooling such as cargo-zigbuild — typically because someone is building on Ubuntu 24.04 (glibc 2.39) but needs to ship a binary that runs on Ubuntu 18.04 (glibc 2.27) or RHEL 7 (glibc 2.17).\n\nRendered",
  "title": "[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets"
}