Bug: oleaut32 not linked

[Jake-Shadle]

Which crate is this about?

windows

Crate version

0.32.0

Summary

When building rfd from the main branch https://github.com/PolyMeilex/rfd/blob/efc9a28bff7da44785c3aa5b2cbaa097c08339b5/Cargo.toml#L33-L40, we get multiple linker errors for undefined symbols, all of them from oleaut32.lib

lld-link: error: undefined symbol: __declspec(dllimport) SysStringLen
>>> referenced by C:\.cargo\registry\src\github.com-1ecc6299db9ec823\windows-0.32.0\src\core\bindings.rs:1191
>>> libwindows-d346ead19c287673.rlib(windows-d346ead19c287673.windows.0beadc8f-cgu.4.rcgu.o):(windows::core::bindings::BSTR::len::haabceceb859863db)
>>> referenced by C:\Users\ark\.cargo\registry\src\github.com-1ecc6299db9ec823\windows-0.32.0\src\Windows\Win32\Foundation\mod.rs:247
>>> libwindows-d346ead19c287673.rlib(windows-d346ead19c287673.windows.0beadc8f-cgu.7.rcgu.o):(windows::Windows::Win32::Foundation::BSTR::len::hb661c02e23f8c8d1)

lld-link: error: undefined symbol: __declspec(dllimport) SysAllocStringLen
...

lld-link: error: undefined symbol: __declspec(dllimport) SysFreeString
...

lld-link: error: undefined symbol: __declspec(dllimport) SetErrorInfo
...

lld-link: error: undefined symbol: __declspec(dllimport) GetErrorInfo
...

Expected behavior

All relevant libraries should be linked by the windows crate.

Actual behavior

oleaut32.lib is not added as a linker arg, thus linking fails.

Additional comments

I've temporarily fixed this in PolyMeilex/rfd#57 by explicitly adding oleaut32 to the linker args, but IMO this should be fixed in the windows crate, not downstream crates.

[kennykerr]

I am able to link these functions via the windows crate. Can you share a minimal repro?

[Jake-Shadle]

So I tried making a minimal repro but was unable to, unfortunately. This was originally found in a large closed source repo when I bumped rfd to use the 0.32.0 version in PolyMeilex/rfd#56, and it only happens on a native Windows machine with the regular MSVC toolchain, we didn't observe it happening when cross-compiling from Linux.

This is my first encounter with the windows crate so I'm not entirely sure how it works, but I did find it odd that these function are all marked as #[link(name = "windows")] and were all changed in #1432, but....oleaut32 is where those functions live? But it is interesting that rfd with 0.30 worked fine for us, and going to 0.32 which included the above change broke. I might try to make another repro again, but I'm not sure what exactly provokes the behavior in our larger project that isn't seen on a smaller scale.

[repi]

maybe something related to that we (@Jake-Shadle and I work on the same project) use the faster LLD linker instead of the default MSVC linker for our project?

[kennykerr]

The windows crate provides its own umbrella libs, called windows.lib, that provides imports for all of the functions declared by the windows crate. This is done to avoid a linker dependency on the Windows SDK.

https://github.com/microsoft/windows-rs/tree/master/crates/targets/x86_64_msvc/lib

All target crates can be found here:

https://github.com/microsoft/windows-rs/tree/master/crates/targets

That's why it links to "windows" rather than "oleaut32".

The change you're noticing is probably #1432 but that was done intentionally to use a consistent lib for all imports.

[kennykerr]

use the faster LLD linker instead

Does it repro with the default MSVC toolchain?

[Jake-Shadle]

Apparently our project stopped linking via link.exe a while ago due to some kind of resource collision, and we've used lld-link exclusively on windows for 2+ years now and never noticed.

[kennykerr]

I haven't tried it myself, but it sounds somewhat experimental. rust-lang/rust#39915 (comment)

I'm happy for you to use it but I'm not really a linker expert so can't really suggest what might be wrong.

If you can't repro using the MSVC linker then at least you'll know where to begin your research.

[Jake-Shadle]

No, that issue is referring to using the rust LLD bundled with the rust compiler, lld-link is the LLD shim that is part of the default clang/LLVM toolchain, and has been stable and producing valid Windows binaries for several versions now.

Now that I understand the windows.lib shim thing I'll revert my PR to rfd to add oleaut32 as a link argument since it should work in normal cases and just explicitly add it our project since we already link multiple other SDK libs and thus require it anyways.

I think I'll close this issue for now since this seems to be something messed up in our setup, but perhaps someone else will run into a similar issue in the future and we can properly figure it out.