Meaning of #[link] kinds

[retep998]

@retep998

@alexcrichton

That's because this is incorrect. When a linker pulls in a static library it typically only pulls in the parts that are needed, not the entire library. This means that if you create a Rust dylib which links to a native static library it may not actually include all of the static library, which in turn can cause future linkage to fail.

A .lib can be a static library or a dynamic library. A .lib can either be bundled into the .rlib or passed to the linker independently. Here we have two boolean situations, so 2*2 = 4 possible combinations. All 4 combinations are legal in the Windows world.

1. Linking a .lib that provides dynamic symbols and not bundling it into the .rlib. dllimport is applied to externs, and the .lib is passed along to every linker invocation that uses that .rlib. If turned into a .dll, the symbols from the .lib are not re-exported. Currently corresponds to kind=dylib.
2. Linking a .lib that provides static symbols and not bundling it into the .rlib. dllimport is not applied to externs, and the .lib is only passed to the first immediate linker invocation. If turned into a .dll, the symbols from the .lib are re-exported with dllexport.
3. Linking a .lib that provides dynamic symbols and bundling it into the .rlib. dllimport is applied to externs, but the .lib is not passed to the linker. If turned into a .dll, the symbols from the .lib are re-exported with dllexport but still pointing at the original .dll, not the Rust .dll.
4. Linking a .lib that provides static symbols and bundling it into the .rlib. dllimport is not applied to the externs, and the .lib is not passed to the linker. If turned into a .dll, the symbols from the .lib are re-exported with dllexport. Currently corresponds to kind=static.

What I would really like is a kind that corresponds to #2.