x86_64-pc-windows-gnu image 0.2.5: link failure — `GetHostNameW` missing from mingw-w64

[coconutbird]

Summary

Building a Rust nightly project with cross build --target x86_64-pc-windows-gnu using the 0.2.5 image fails at link time with an undefined reference to GetHostNameW. All Rust compilation succeeds — only the final mingw linker step fails.

Environment

• Host: aarch64-apple-darwin (Apple Silicon, Docker Desktop with Rosetta)
• Rust toolchain: nightly-x86_64-unknown-linux-gnu — 1.96.0-nightly (80282b130 2026-03-06)
• cross version: 0.2.5
• Docker image: ghcr.io/cross-rs/x86_64-pc-windows-gnu:0.2.5
• CROSS_CONTAINER_OPTS: --platform linux/amd64 (required on ARM64 host)

Error

error: linking with `x86_64-w64-mingw32-gcc` failed: exit status: 1
  ...
  /rust/lib/rustlib/x86_64-pc-windows-gnu/lib/libstd-949922d303bba3ab.rlib(std-*.rcgu.o):
    .../std/src/sys/net/hostname/windows.rs:15: undefined reference to `GetHostNameW'
  collect2: error: ld returned 1 exit status

The linker command does include -lws2_32, so the library is being linked — but the mingw-w64 version in the image doesn't export GetHostNameW.

Root Cause

Rust nightly's std now uses GetHostNameW (in std::sys::net::hostname::windows). This function requires a newer mingw-w64 than what's bundled in the 0.2.5 image. The x86_64-unknown-linux-gnu and aarch64-unknown-linux-gnu images work fine — this only affects the Windows GNU cross-compilation image.

Reproduction

# Any Rust project using tokio or std networking should reproduce this
cargo init --name repro && cd repro
echo 'tokio = { version = "1", features = ["full"] }' >> Cargo.toml
cat > src/main.rs << 'EOF'
#[tokio::main]
async fn main() {
    println!("hello");
}
EOF
CROSS_CONTAINER_OPTS="--platform linux/amd64" cross build --target x86_64-pc-windows-gnu

Expected Behavior

The build should link successfully, as it does for the Linux targets.

Suggested Fix

Update the mingw-w64 toolchain in the x86_64-pc-windows-gnu Docker image to a version that includes GetHostNameW in its ws2_32 import library.

[Raniz85]

I ran into this today (with 1.94.0). Upgrading the base images to Ubuntu 24.04 fixes it.

I have a PR incoming that updates both the i686-pc-windows-gnu image and x86_64-pc-windows-gnu images as soon as I've tested to see that the i686-image also builds after the upgrade

[Raniz85]

This is likely the same underlying issue as #1737 (that error also mentions GetHostNameW)

[Raniz85]

PR opened, #1755.

In the meantime, you can use this image:

ghcr.io/raniz85/cross/x86_64-pc-windows-gnu:24.04

Cross.toml

[target.x86_64-pc-windows-gnu]
image = "ghcr.io/raniz85/cross/x86_64-pc-windows-gnu:24.04"

$ cross run --target x86_64-pc-windows-gnu
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.94.0 (4a4ef493e 2026-03-02)

info: self-update is disabled for this build of rustup
info: any updates to rustup will need to be fetched with your system package manager
   Compiling hello v0.1.0 (/project)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
     Running `env -u CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUNNER wine /target/x86_64-pc-windows-gnu/debug/hello.exe`
Hello, world!