windows-gnu target compatibility with toolchains providing LLVM tools only

[mati865]

Rust currently assumes all GNU libraries and tools are present. This is not the case when using LLVM only toolchains like this one: https://github.com/mstorsjo/llvm-mingw

Remaining issues:

• LLD doesn't work with version-scripts (MinGW: enable dllexport/dllimport #72049)
• Rust explicitly links libgcc, libgcc_eh, libgcc_s

Opening the issue so interested people can track it easily.

[mati865]

@rustbot modify labels: +O-windows-gnu

[mati865]

cc @petrochenkov for the second issue, we just need possibility of providing custom late_link_args_dynamic and late_link_args_static.

[petrochenkov]

@mati865
Do you mean ability to pass -C link-args-dynamic / -C link-args-static on the command line in addition to the target spec, or ability to drop the target spec args and start from scratch with regular -C link-args?

[mati865]

@petrochenkov in this specific case we need to replace libgcc with compiler-rt and libgcc_eh or libgcc_s with libunwind. late_link_args hopefully could be left intact but I have to verify that.
Adding new target would do the trick but it might be an overkill if things can work with existing target.

[petrochenkov]

So, I think this is a job for #[link(cfg(...))] (if we want to avoid a new target).

One cfg feature is provided by the compiler and allows to discern between the link_args_dynamic and link_args_static at link time.

Another cfg feature is a regular cargo feature of the src/libunwind crate which allows to switch between "LLVM toolchain" (compiler-rt + libunwind) and "GCC toolchain" (libgcc + libgcc_eh).

Then 8e3467c is reverted and all the linking is done through #[link] attributes in src/libunwind.

#[link(name = "gcc_s", cfg(all(rustc_detect_dynamic, gcc_toolchain)))]
#[link(name = "gcc_eh", cfg(all(not(rustc_detect_dynamic), gcc_toolchain)))]
#[link(name = "unwind", cfg(not(gcc_toolchain)))]
extern {}

or something.

[petrochenkov]

This way we'll eliminate late_link_args_(dynamic,static) stuff from target specs which felt like a hack to me since its introduction.

Before 8e3467c #![no_std] programs (or rather programs not depending on src/libunwind) didn't link to the exception support libraries, which seems like the right thing to me.

With these options moved to the target spec they apply to all programs, even no-std ones.
(In this sense any libraries linked from target specs seem at least suspicious.)

[mati865]

I've tried similar approach in #71001
That makes i686 executables depend on having libgcc_s-dw2-1.dll (or libunwind.dll) either in PATH or next to them.

I wanted to avoid new target if possible because we will definitely need new target to allow linking with UCRT instead of MSVCRT since one cannot mix libraries build with UCRT and MSVCRT.
C/C++ toolchains using UCRT already exists in the wild and I'm already being asked when it'll be possible to use Rust built libraries with them.

EDIT: For x86_64 we could even build libunwind as part of std and link it statically but this somehow results in errors because proc_macro crates are no longer built (just like previously on musl with +crt-static).

[petrochenkov]

#71001 didn't use cfg(rustc_detect_dynamic) proposed in #72241 (comment) though.
With it executables won't depend on gcc_s.

[mati865]

Wait, so we can use features here not only when building std but also when building user code? 😮

[petrochenkov]

@mati865
Yes, cfgs in #[link] are serialized into crate metadata "as is" and evaluated only when the final binary is build.
That's how cfg(target_feature = "crt-static") works, for example.