Windows GNU Targets Failing with LTO

[coltonhurst]

Hello 👋

I am experiencing build failures with rustls-platform-verifier when building for release with lto when targeting the x86_64-pc-windows-gnu target.

I created an example repository with the potential bug: https://github.com/coltonhurst/rustls-platform-verifier-lto-bug

My log.txt containing the errors is here:

log.txt

Thank you!

[ctz]

Is this rust-lang/rust#109797?

[complexspaces]

I'm not sure if its that exact bug or not, but this looks like a compiler regression for sure. These are my reasons for thinking so:

• We don't perform any manual linkage in this library and let winapi or windows_sys handle that part.
• The referenced symbol missing is coming from the standard library's random generation APIs, so the linker is having a hard time finding the right parts for our library's object, not the final binary failing to find something from this crate.

I spent some time checking compiler versions and this seems like it regressed in 1.80.0 for me locally. Switching to fat LTO also fixes it, further indicating a bug in the toolchain.

This build works without any issues: cargo +1.79.0 build --target x86_64-pc-windows-gnu --release
This fails and produces the same linker error: cargo +1.80.0 build --target x86_64-pc-windows-gnu --release

[complexspaces]

FWIW, I would personally recommend not using the GNU toolchain for Rust on Windows if possible. Its full of bugs in the toolchain/runtime layer, resulting in a lot of non-ideal workarounds or features being disabled in Rust tooling/std because of it.

If Bitwarden doesn't want to use MSVC (or any MS tooling), clang and the LLVM toolchain might work instead combined with the strategy in this blog if needed.

[coltonhurst]

Ah yes, looks like it could be the compiler regression rust-lang/rust#109797.

Fair point regarding GNU for Rust on Windows. Right now our Go binding is built with our Rust SDK with cgo, which doesn't seem to have great support for anything besides gcc. The CGo Wiki mentions only gcc will work 🥲 though we have tried other compilers. Maybe in the future we can find a better solution.

@ctz @complexspaces thanks for the detailed investigation, as usual!

[cpu]

I think this can probably be closed since there's no action to take in this crate, and there's a documented workaround for the compiler regression.

(If I'm wrong and there's a reason to keep this open feel free to flip it back!)