Bug: windows-targets v0.48.3 doesn't build on i686-pc-windows-gnu

[CryZe]

Which crate is this about?

windows-targets

Crate version

v0.48.3

Summary

The linker is unable to link the crate, "all" the symbols are corrupted. This did not happen with v0.48.1 (I couldn't test v0.48.2 so far).

https://github.com/LiveSplit/livesplit-core/actions/runs/5895964605/job/15993579191?pr=712#step:9:239

Toolchain version/configuration

(This is inaccurate because I did build with stable-i686-pc-windows-gnu 1.71.1)

Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\cryze.rustup

installed toolchains

stable-i686-pc-windows-gnu
stable-x86_64-pc-windows-gnu
stable-x86_64-pc-windows-msvc (default)
nightly-x86_64-pc-windows-msvc

installed targets for active toolchain

wasm32-unknown-unknown
wasm32-wasi
x86_64-pc-windows-msvc

active toolchain

stable-x86_64-pc-windows-msvc (default)
rustc 1.71.0 (8ede3aae2 2023-07-12)

Reproducible example

You can clone this: https://github.com/CryZe/livesplit-core/tree/auto-splitter-config-builder

And build it like in the CI:

cargo +stable-i686-pc-windows-gnu test -p livesplit-core --features std,more-image-formats,image-shrinking,rendering,default-text-engine,wasm-web,font-loading,software-rendering --target i686-pc-windows-gnu

Crate manifest

No response

Expected behavior

It links

Actual behavior

It doesn't link

Additional comments

No response

[ChrisDenton]

At first glance this looks like rust-lang/rust#112368

EDIT: Oh but apparently that shouldn't cause a failure to link. Hrm.

[riverar]

Opinion: I never actually got the gcc that ships with Rust gnu toolchain to ever really work correctly; it always seemed very quirky. Instead, here on windows, we use an external gcc configured via .cargo\config (see our CI workflow).

Using that setup above, everything works™️.

I'll take a closer look at your error using the native toolchain in a few. Ping @mati865 for awareness.

[mati865]

Symbols are not corrupt. Old Binutils (<2.40) show warning about attributes it doesn't know. Those unknown to old Binutils are used only to limit amount of exported symbols.

Unfortunately the real error is not visible, maybe it's just buried in the logs. I recommend trying with newer Binutils (just add binaries to PATH) or LLD. Of that doesn't workaround the problem maybe it will at least show what is wrong.

[riverar]

The warning is benign indeed. ld (binutils 2.38) is actually crashing, resulting in missing information in your CI logs. There has been some churn in this area in recent releases (https://github.com/bminor/binutils-gdb/commits/master/ld). Given this builds in binutils 2.41, it looks like it's already fixed. So at this point, I'd recommend using an external binutils suite as suggested above until the Rust gnu toolchain gets updated.

Closing as there's nothing here for windows-rs to do, but feel free to keep the discussion going.

[V0ldek]

I'd recommend using an external binutils suite as suggested above until the Rust gnu toolchain gets updated.

Is this tracked anywhere in rust-lang, or should we raise this as an issue there?