{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidzpeaxgffri2mpfouiomnvdbwbvobcl4jemashz3cceq5bnsuyju",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3misiuxeyrjq2"
  },
  "path": "/t/pre-pre-rfc-dynamic-library-proposal/24135#post_2",
  "publishedAt": "2026-04-05T18:32:07.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "↩︎"
  ],
  "textContent": "LouChiSoft:\n\n> So where does Rust fit in? Well I think the same pattern could be applied to Rust as well when compiling dynamic libraries. Only instead of getting a platform specific `.lib` file you get something like a `.rimport` file or something. similar. The goal would be that during compilation of the library every publicly accessible symbol you have would be exported into the `.rimport` file along with the ABI that it was compiled with. No fixed ABI here, just the one that toolchain used at the time it was compiled.\n\nGood news: these files already exist. They are called metadata files, with extension `.rmeta`. They contain _exactly_ the information that the compiler of some dependent code needs in order to compile against the library.[1]\n\nSo, you don’t need to invent a new file format; you “just” need:\n\n  * sufficient ABI stability/versioning, and\n  * a way to tell Cargo to accept a pre-existing `.rmeta` rather than compiling all dependencies from source.\n\n\n\n* * *\n\n  1. Note that some of this information is things like “the bodies of inlinable functions”, so you might need to prohibit inlining if you want the dynamic library to be separately updateable. ↩︎\n\n\n",
  "title": "[Pre-Pre-RFC] Dynamic library proposal"
}