Support renames with `link(name = "...", kind = "raw-dylib")`

compiler
1

The latest PyO3 version shipped changes to our windows builds to use the raw-dylib feature.

I'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>.

Without 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.

This 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).

It 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.

Does this seem a reasonable ask?

1 Like
2

I wonder if macros are supported in the link name field. If so you could do #[link(name = env!("PYTHON_DYLIB_NAME"), kind = "raw-dylib")].

3

apparently not Rust Playground

4

Indeed, I tried that :cry:

I would be happy to consume an env!() -based name in the link attribute if that's preferred.

5

I wonder if there is a reason it can't allow any constant.

6

Seems very reasonable.