{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif2aopdrcdcrume3e7mamnr7wyrzbxqnrb66nbvqgg7lnpjcf6owy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml6ynbv6qne2"
  },
  "path": "/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225#post_9",
  "publishedAt": "2026-05-06T14:43:07.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "nikkon-dev:\n\n> This is quite a trivial task. A standalone binary may either automatically download the required glibc version sources or use whatever sources the user provides (not from the linked libc.so.6 on your system).\n\nOh, I was thinking of something that would take my existing libc.so.6 and make the stub directly from it. Building from sources seems complicated for cross-compilations, but I understand this is not a trivial problem that is guaranteed to be amenable to such \"shortcuts\".\n\nnikkon-dev:\n\n> No. This is way outside of the scope of this RFC. Moreover, I do not know of any success stories involving libstdc++/libc++ from languages other than C++. If it were possible with reasonable effort, Rust could automatically use libraries that expose API as C++ classes with std::* types. In other words, why would you even need something like that?\n\nYeah, I suppose that would be something for one of the C++ binding crates to work with rather than `rustc` itself.",
  "title": "[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets"
}