Add support for x86_64-pc-windows-gnullvm target

[mati865]

This is Tier 3 target but lack of windows-rs support is one of the blockers for testing it in real world. Given the changes here are minimal I think there should be no problem with them.

[ghost]

All CLA requirements met.

[kennykerr]

Hey, thanks for the contribution! Generally, it's helpful to start with an issue to explain the problem you're trying to solve before opening a PR. For example, I'm not familiar with this target or why these changes are necessary. Also, we'd need to add CI tests to validate it works if this is something we're going to support.

[mati865]

Sorry, I thought it will be more obvious.

Not so long time ago, new Tier 3 windows-gnullvm targets were added to Rust. They are similar to windows-gnu but not drop in compatible because they are based purely on LLVM + mingw-w64.

Trying to build anything that uses windows-rs with those targets ends up with error saying -lwindows cannot be found. This library is provided by windows_x86_64_gnu crate for x86_64-pc-windows-gnu target. With x86_64-pc-windows-gnullvm however this crate is not used right now because of different target triple.
This PR makes x86_64-pc-windows-gnullvm also depend on that library so libwindows.a is found.

Also, we'd need to add CI tests to validate it works if this is something we're going to support.

Given the fact it's Tier 3 target it cannot be used out of the box and needs to be built using unstable -Z build-std or by manually building Rust with support for it.
I can try to add it to CI but I'm not sure if you want to officially support it or block CI on it that early.

[kennykerr]

Sounds good - thanks for the explanation. @rylev thoughts?

[riverar]

(See below.)

[riverar]

This looks fine, but I think we should break this out into its own target.

That will let us generate newer more efficient libs (#1787) and avoid mixing non-LLVM libs with LLVM tooling, something that will undoubtedly break sooner/later. It will also give us a natural spot to put any LLVM-specific linker flags, tricks, etc. in the future.

Recommended action: Restore existing *_gnu crates and create *_gnullvm targets.
Future action: Restore and retarget #1787 to shiny new _gnullvm target crate

[kennykerr]

Also, make sure we have open issues for outstanding work.

[mati865]

Thank you for the review.
I do agree that having separate target would be cleaner solution (see #1847 that I hacked together to use generate import libs with LLVM for AArch64). Had hoped to quickly bandage it until raw-dylib is stabilised but seems like the progress stalled there.
I'll look into it next week due to time constrains, converting to draft until then.

I want to clarify some things;

That will let us generate newer more efficient libs (#1787)

They are smaller but otherwise work almost the same way.

avoid mixing non-LLVM libs with LLVM tooling, something that will undoubtedly break sooner/later.

Binutils output legacy import libraries format (sometimes called long import libraries) while LLVM outputs short import libraries (just like MSVC does).
LLVM supports reading both import libraries format and AFAIK there are no plans to get rid of the old one. Bintuils on the other hand supports legacy import libraries just fine but short import libraries are problematic: tools cannot output that format and reading works only partially (there are many bugs).
So as long as one uses lowest common denominator which are the legacy import libraries created by binutils for i686/x86_64 there are no compatibility concerns. Binutils doesn't support ARM/AArch64 so LLVM is the only toolchain here.

It will also give us a natural spot to put any LLVM-specific linker flags, tricks, etc. in the future.

That is true, LLVM can benefit from multiple things that are supported by MSVC but not by Binutils.

Also, make sure we have open issues for outstanding work.

Could you elaborate a bit? Should I open some kind of tracking issue?

[kennykerr]

FYI @sivadeilra @dpaoliello for recurring (lack of) raw-dylib issues. 😉

[kennykerr]

Could you elaborate a bit? Should I open some kind of tracking issue?

Yes, clearly this work is more involved or at least more contentious than initially suspected. It would be helpful to have an issue that clearly states what these two PRs aim to solve here so we can discuss and agree on a solution before proceeding to PRs.

Oh and by outstanding work I meant whatever other issues might take longer to land, such as the CI validation of Tier 3 targets.

[mati865]

Opened #1881