{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigv73qwkkhukfg653duj5ar22jcr3ei37wg6w34km55azc2zk244e",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml65soriukb2"
  },
  "path": "/t/pre-rfc-target-glibc-proposal-to-add-native-support-for-glibc-versions-for-the-gnu-targets/24225#post_3",
  "publishedAt": "2026-05-06T05:50:36.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "> Are there plans on making the tool that does the \"local glibc -> stub library\" standalone? I can forsee this being _very_ useful even outside of Rust.\n\nThis 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\n> Would a linker script be easier (it may well might not be, but I'm curious if it was considered)?\n\nLinker script is generated/used under the hood anyway. It can be preserved next to the generated stub libraries.\n\n> Also, has an equivalent for libstdc++ and/or libc++ been considered?\n\nNo. 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?",
  "title": "[Pre-RFC] target-glibc: Proposal to add native support for GLIBC versions for the -gnu targets"
}