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.

7

I looked into the macro thing and I think that would be a pretty complex language change to allow macros in attribute meta args, and might even end up with some ambiguity. It seems that there is a lot of cursedness here, according to Jana, the resident attribute parsing expert.

So even though it looks a bit ironic, I'd expect the compiler raw-dylib remapping to actually be simpler to implement.

1 Like
8

I had a quick look and concluded the same thing; I started playing around with a patch to support -l raw-dylib=..., will see if I can finish it off in the near future.

9

And how hard would referencing consts in #[link] be?

10

This "just" needs us to be able to reference paths in attributes, which is challenging to implement. I've been meaning to get back into implementing that.

It's easy to implement if you turn [link] into a builtin macro, but that comes with its own set of problems, and is not the way I'd like to see things go.

11

We only support that in #[attr = Expr], because it was allowed in the past if you passed the expr through a macro invocation

Supporting that further is hard, because we'd a) need to figure out the story about how this interacts with attribute macros. #[attr = value] is never a macro, so that sidesteps it there, and b) we would need to parse attributes much earlier or parse macro invocations in attributes much later which would be rather difficult and/or hacky to implement.