{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicj7aseb7lopbhsnw273ugr3vgju2slshw6qz5ldtezzeacgqwxry",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mp7yqhx7bvl2"
  },
  "path": "/t/support-renames-with-link-name-kind-raw-dylib/24415#post_1",
  "publishedAt": "2026-06-26T14:06:39.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "The latest PyO3 version shipped changes to our windows builds to use the `raw-dylib` feature.\n\nI'm experiencing a fairly significant pain point with `raw-dylib` - it can't be \"renamed\" because `raw-dylib` isn't an accepted `kind` to `rustc -l <kind>=<name>:<rename>`.\n\nWithout `raw-dylib` PyO3 was accepting any user-supplied name for `libpython` and was passing (via build script) the equivalent of `-l dylib=pythonXY:<real-name>`, and we then decorated `extern` blocks with `#[link(name = \"pythonXY\")]`. With `raw-dylib` we couldn't keep this structure and switched to macros to generate conditional `#[cfg_attr(<condition>, link(kind = \"raw-dylib\", name = \"<name>\"))]` for a known set of `<condition>`, `<name>` pairs.\n\nThis of course doesn't work for all possible user-supplied namse so we'll have to find ways to accept those (probably falling back to `cdylib` linking in this case).\n\nIt would be nice to reduce this complexity. I think a possible way to do it would be to allow passing `-l raw-dylib=pythonXY:<name>` to rustc (via cargo), which would have the effect of changing blocks marked `#[link(kind = \"raw-dylib\", name = \"pythonXY\")]` to link against a final library name of `<name>` supplied on the command line.\n\nDoes this seem a reasonable ask?",
  "title": "Support renames with `link(name = \"...\", kind = \"raw-dylib\")`"
}