x86_64-pc-windows-gnu target works with Clang, but assumes the gcc alias exists always

[amyspark]

I tried this code to install cargo-c manually (see https://invent.kde.org/graphics/krita/-/blob/master/3rdparty/ext_heif/CMakeLists.txt#L98):

cargo install --path <source for cargo-c> -j 12 --root <install prefix for CI>

I expected to see this happen: cargo-c is happily linked and installed

Instead, this happened:

error: linker `x86_64-w64-mingw32-gcc` not found
  |
  = note: El sistema no puede encontrar el archivo especificado. (os error 2)

error: could not compile `winapi-x86_64-pc-windows-gnu` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cargo-c v0.8.1+cargo-0.53 (E:\krita-win\b_deps_clang64\ext_heif\ext_cargo_c-prefix\src\ext_cargo_c)`, intermediate artifacts can be found at `E:\krita-win\b_deps_clang64\ext_heif\ext_cargo_c-prefix\src\ext_cargo_c\target`

This is because https://github.com/msys2/MINGW-packages/pull/10651 removes the gcc alias that allowed this (potentially unsupported, but working use case) to work.

I don't know how to override the linker to sidestep this (especially on a CI context like the one I linked), but it should be possible to dynamically detect the linker and construct the target accordingly, especially now that there are alternative MinGW flavors.

Meta

rustc --version --verbose:

rustc 1.57.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-pc-windows-gnu
release: 1.57.0
LLVM version: 13.0.0

Backtrace

``` warning: a `-j` argument was passed to Cargo but Cargo is also configured with an external jobserver in its environment, ignoring the `-j` parameter Installing cargo-c v0.8.1+cargo-0.53 (E:\krita-win\b_deps_clang64\ext_heif\ext_cargo_c-prefix\src\ext_cargo_c) Updating crates.io index Compiling winapi-x86_64-pc-windows-gnu v0.4.0 Compiling winapi v0.3.9 Compiling proc-macro2 v1.0.36 Compiling libc v0.2.119 Compiling syn v1.0.86 Compiling serde_derive v1.0.136 Compiling serde v1.0.136 Compiling log v0.4.14 Compiling memchr v2.4.1 Compiling crc32fast v1.3.2 Compiling tinyvec_macros v0.1.0 Compiling matches v0.1.9 error: linker `x86_64-w64-mingw32-gcc` not found | = note: El sistema no puede encontrar el archivo especificado. (os error 2) error: could not compile `winapi-x86_64-pc-windows-gnu` due to previous error warning: build failed, waiting for other jobs to finish... error: failed to compile `cargo-c v0.8.1+cargo-0.53 (E:\krita-win\b_deps_clang64\ext_heif\ext_cargo_c-prefix\src\ext_cargo_c)`, intermediate artifacts can be found at `E:\krita-win\b_deps_clang64\ext_heif\ext_cargo_c-prefix\src\ext_cargo_c\target` Caused by: build failed mingw32-make[3]: *** [ext_heif\CMakeFiles\ext_cargo_c.dir\build.make:104: ext_heif/ext_cargo_c-prefix/src/ext_cargo_c-stamp/ext_cargo_c-install] Error 101 mingw32-make[2]: *** [CMakeFiles\Makefile2:2174: ext_heif/CMakeFiles/ext_cargo_c.dir/all] Error 2 mingw32-make[1]: *** [CMakeFiles\Makefile2:2319: ext_heif/CMakeFiles/ext_libheif.dir/rule] Error 2 mingw32-make: *** [Makefile:864: ext_libheif] Error 2 ERROR: Building of ext_libheif failed ```

[jub0t]

I get

build failed
error: could not compile `winapi-x86_64-pc-windows-gnu`

[amyspark]

This can be sorted out by forcing a linker through RUSTFLAGS (which I've done successfully with Android). I would be happy to see it be dynamically resolved, if possible.

[mati865]

This is because msys2/MINGW-packages#10651 removes the gcc alias that allowed this (potentially unsupported, but working use case) to work.

You can select linker with -C linker when building natively or by defining CARGO_TARGET_X86_64_PC_WINDOWS_GNU_LINKER