{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaxewtery75c3uhifnhhorm5od5j3554rvfh7ukhjdi5tmhvnb6eq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlehp4vd7i62"
  },
  "path": "/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225#post_16",
  "publishedAt": "2026-05-08T19:10:51.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "@comex"
  ],
  "textContent": "comex:\n\n> cfsetspeed\n\n@comex gave a really great example.\n\nI just want to\n\nzackw:\n\n> If so, please clarify what your feature is meant to do.\n\n@comex gave really good examples of where this would be useful (thank you!)\n\nI just want to clarify that this feature is literally about making what zig-build does natively in Rust without depending on the zig infrastructure.\n\nThis scenario illustrates a situation where control over symbol versioning is limited.\n\nConsider a static library that uses the `cfsetspeed` function. 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\nThe static library itself references `cfsetspeed` without specifying an exact symbol version. Therefore, the linker determines the version. It selects the latest available version within the C library at the time of linking on the build system. This static library could be written in various programming languages, including Rust, C, or C++.\n\nThis proposal suggests bringing the stub libc libraries generated from the abilists files in at the moment, right before linking. This, to some extent, \"fakes\" a sysroot override.",
  "title": "[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets"
}