{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigpisc5mlsusrnbs5x43kmi57dqz5lkogrfkmaaso7hpe5ktfgypa",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlkrwayvc5t2"
  },
  "path": "/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225#post_17",
  "publishedAt": "2026-05-11T07:19:37.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "the aforementioned PR"
  ],
  "textContent": "nikkon-dev:\n\n> During the linking process, the final executable will incorporate either `cfsetspeed@GLIBC_2.33` or `cfsetspeed@GLIBC_2.19`. The specific version chosen depends on the build environment.\n\nIf I read the aforementioned PR correctly, that's not what happens. Rust projects will always use `cfsetspeed@GLIBC_2.2.5` (on x86-64). The version is hard-coded and independent of the glibc version on the build machine.\n\nnikkon-dev:\n\n> I 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.\n\nThat's the crux of the issue, IMO. You're trying to do something that upstream does not support. Providing that support downstream will be an enormous amount of effort that's also going to be duplicated if Zig, Rust, ... all do it on their own. What a waste of effort.\n\nHonestly using Zig tooling for this as a piece of shared infrastructure that works across multiple languages seems quite appealing.\n\nBased on that upstream position, glibc seems like a lost cause for your usecase. Is musl an option?",
  "title": "[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets"
}