Tracking issue for #[link(kind)] connecting libraries on Windows

[alexcrichton]

Tracking issue for rust-lang/rfcs#1717

• Implement -l[kind=][oldname:]libname.
• Implement lib<->symbol association and emit dllimport for dylib symbols.
• Implement kind="static-nobundle".

[dgrunwald]

If I specify #[link(name="pythonXY")] on 30 extern C blocks, and then compile with rustc -l dylib=pythonXY:python27, then python27.lib is passed to the linker 30 times.

Not sure if that's actually a problem, but maybe Rust could de-duplicate the linker arguments?

[dgrunwald]

Also, is it intentional that these changes are insta-stable?

cc @vadimcn

[vadimcn]

@dgrunwald: Could you coalesce those 30 extern blocks into one? You probably did it to keep extern declarations in the same file/module as the code using them, but this isn't really how we thought about extern blocks when designing Rust FFI.

The problem with de-duping is that most unix linkers resolve references using only libraries to the right on the command line. So if you know that lib1 depends on something in lib2, they must appear in that order (even if lib2 has already appeared to the left of lib1).

Our approach so far has been to simply emit libraries in the order they appear in the source, followed by the ones specified on the command line.

In order to optimize this, we'd need to provide some way of specifying library dependencies (e.g. "libraries {attached to the same extern block | within the same module | within the same source file} are guaranteed to be given to the linker in the same order"). For starters, some motivated person would need to write an RFC :)

Also, is it intentional that these changes are insta-stable?

Sort of. The changes in handling of dllimport did not create any new syntax that could be feature gated. We could still use a #[feature(...)] to toggle the new behavior, but it's a bit too subtle for my liking: There would be no error message telling the user that this is feature-gated; they'd simply get a linker error.

[dgrunwald]

python3-sys is structured in the same way as the python headers: one .rs file per .h file; with the declarations within the file in the same order as in the .h file.
Because the Python headers have lots of macros (which I manually translate into constants or #[inline] fns), I frequently close the extern "C" block, define the macro functions/constants, and then re-open the extern "C" block. This approach means that python3-sys has 95 #[link(name="pythonXY")] extern "C" blocks in total.

When a new Python version is released, I diff the new Python headers against the old headers and apply the same changes to the Rust code (using #[cfg] attributes for new functions). This would be much more difficult if I had to keep everything in a single extern block.

[retep998]

@dgrunwald A similar situation will occur for me in winapi = "0.3". Preserving duplicates isn't strictly necessary everywhere. link.exe and lld in particular aren't dumb the way unix linkers are, so we can trivially deduplicate libraries for the msvc linker without breaking anything, and eventually when we switch to LLD for all the other targets we can deduplicate libraries everywhere. Until then though, we need some sort of solution.

[dgrunwald]

The current logic seems to be: if both #[link(X)] and -l X:Y is specified, ignore the position of the -l X:Y command-line argument and use all the #[link] positions instead.

What if we just did this the other way around: if both are specified, ignore the #[link] positions and use the single -l X:Y position instead.