Fail to link i686 staticlib with MSVC

[upsuper]

See my test repo: upsuper/rust-msvc-link-test

• Build the crate with i686-pc-windows-msvc toolchain
• Build the C++ file with cl.exe from MSVC 2015
• Link them together via link.exe from MSVC 2015

(The 32bit MSVC 2015 toolchain locates at "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86" for me)

It shows linker error like:

test.lib(test.0.o) : error LNK2019: unresolved external symbol __imp__?after@nsCSSPseudoElements@@2PAVnsICSSPseudoElement@@A referenced in function _test
test.lib(test.0.o) : error LNK2019: unresolved external symbol _?before@nsCSSPseudoElements@@2PAVnsICSSPseudoElement@@A referenced in function _test

Using dumpbin -symbols to analyse main.obj and test.lib shows that, in main.obj, the symbols are

008 00000000 SECT3  notype       External     | ?after@nsCSSPseudoElements@@2PAVnsICSSPseudoElement@@A (public: static class nsICSSPseudoElement * nsCSSPseudoElements::after)
009 00000004 SECT3  notype       External     | ?before@nsCSSPseudoElements@@2PAVnsICSSPseudoElement@@A (public: static class nsICSSPseudoElement * nsCSSPseudoElements::before)

however, in test.lib generated by rustc, the import symbols are

02A 00000000 UNDEF  notype       External     | __imp__?after@nsCSSPseudoElements@@2PAVnsICSSPseudoElement@@A
02D 00000000 UNDEF  notype       External     | _?before@nsCSSPseudoElements@@2PAVnsICSSPseudoElement@@A

Thus the mismatch.

It's even more interesting that the symbol from nested crate is different from the crate of the lib, even though they are both extern symbols.

This issue doesn't show up for 64bit build with proper link_name. The corresponding symbols in rust staticlib with x86_64 toolchain would be:

A15B 00000000 UNDEF  notype       External     | __imp_?after@nsCSSPseudoElements@@2PEAVnsICSSPseudoElement@@EA (__declspec(dllimport) public: static class nsICSSPseudoElement * nsCSSPseudoElements::after)
A15C 00000000 UNDEF  notype       External     | __imp_?before@nsCSSPseudoElements@@2PEAVnsICSSPseudoElement@@EA (__declspec(dllimport) public: static class nsICSSPseudoElement * nsCSSPseudoElements::before)

It could either because of the different prefix (__imp_ vs. __imp__ and _) or the different link type? But the linker also complains about dllimport using on static link symbols for 64bit build.

cc @alexcrichton

[upsuper]

This affects Stylo. See atom_macro.rs. (The test code is also simplified from Stylo case)

[alexcrichton]

Yes I think this may have to do with dllimport at least a little? Right now we blindly apply dllimport to all imports and we rely on the linker to fix up any mistakes. This in general works for most references and will otherwise be fixed by rust-lang/rfcs#1717

The other remaining piece here is that it looks like LLVM is adding a leading _ on x86 which I believe is part of the symbol mangling ABI. You can disable I believe (untested) by changing the attribute to:

#[link_name = "\x01?..."]

That is, add a leading "1 byte" to the symbol and I think it disables the otherwise present name mangling.

[upsuper]

Looks like adding \x01 at the beginning of link_name works. Thanks for the advice.

[upsuper]

FWIW, it seems the warning is simply based on the name having __imp_ prefix. In this case, after I prepend the link_name with \x01, the linker no longer complains about dllimport using on static link symbos for before (but still for after because it still has __imp_ prefix).

[alexcrichton]

Ok cool! Should this be closed?

[upsuper]

Should it? I suppose Rust (or LLVM) should fix this rather than relying on users to prepend an \x01 to link_name?

[retep998]

@upsuper LLVM decorating symbols based on the calling convention is expected behavior and not a bug. It is surprising behavior sometimes, yes, and there are cases where you don't want it, but the majority of the time it does the right thing. Dllimport shenanigans are a different yet known issue #27438

[alexcrichton]

Yes it sounds like here you're basically taking on the name mangling of MSVC yourself, so I don't think there's much we could really do here other than offer this escape hatch.