package mingw-w64-clang-x86_64-rust should target to x86_64-pc-windows-gnullvm

[ArchGuyWu]

As there's only llvm-based toolchain in ucrt64 repo ,the target x86_64-pc-windows-gnu is not the proper one ,and it doesn't work even with package mingw-w64-clang-x86_64-gcc-compat installed.

[1480c1]

https://doc.rust-lang.org/rustc/platform-support/pc-windows-gnullvm.html

should probably ping @mati865 for his opinion

[jeremyd2019]

I think that's being worked on, #13278 is related

[mati865]

As there's only llvm-based toolchain in ucrt64 repo

UCRT64 repo is GCC/Binutils based, CLANG64 is LLVM based.

the target x86_64-pc-windows-gnu is not the proper one ,and it doesn't work

It works fine because of hacks, we have compiled multiple packages with it: https://packages.msys2.org/package/mingw-w64-clang-x86_64-rust

mingw-w64-clang-x86_64-rust should target to x86_64-pc-windows-gnullvm

That is long-term goal but:

1. Getting it to build with pacman under MSYS2 has been troublesome and so far it's even more hacky than using regular *-pc-windows-gnu triples.
2. Ecosystem is not ready yet. Because of the dependencies, migrating right now would break building half of the packages (or more) that we already build with Rust for CLANG64.

[jeremyd2019]

1. Getting it to build with pacman under MSYS2 has been troublesome and so far it's even more hacky than using regular *-pc-windows-gnu triples.

It actually wasn't too bad anymore when I tried it for 1.70.0. It did require 3 rust builds though (but could probably be reduced to 2 based only on my knowledge, somebody more knowledgeable about rust building might be able to do it with 1)

1. built rust 1.69.0 with --target x86_64-pc-windows-gnu,x86_64-pc-windows-gnullvm
2. built rust 1.70.0 with --build --host and --target x86_64-pc-windows-gnullvm AND --enable-llvm-link-shared
3. built rust 1.70.0 without --enable-llvm-link-shared

The 2nd was due to missing symbols from libz and libzstd at least when it tried to link to llvm. This seemed to be because it considered this a cross compile, so did not pass --system-libs to llvm-config. Linking to the shared llvm worked around this because it doesn't need any system libs, but it should also be possible to patch bootstrap to pass --system-libs anyway.

[mati865]

The 2nd was due to missing symbols from libz and libzstd at least when it tried to link to llvm. This seemed to be because it considered this a cross compile, so did not pass --system-libs to llvm-config. Linking to the shared llvm worked around this because it doesn't need any system libs, but it should also be possible to patch bootstrap to pass --system-libs anyway.

I typically patch https://github.com/rust-lang/rust/blob/e94bda3bf13303671427363d1cd93ac5e089f090/compiler/rustc_llvm/build.rs#L160 on these occassions.

• built rust 1.69.0 with --target x86_64-pc-windows-gnu,x86_64-pc-windows-gnullvm

That's good idea, I used to build in the first step --build x86_64-pc-windows-gnu, --host x86_64-pc-windows-gnullvm, --target x86_64-pc-windows-gnullvm which created more mess because that first step had to build 2 compilers+libraries: windows-gnu and windows-gnullvm.

[jeremyd2019]

From #17406 (comment)

Option 3. implies that we have to keep bootstrapping=no for clang and can't revert to yes anymore (unless something is fixed upstream).

Since the issue is a result of us "lying" to rust and turning *-pc-windows-gnu into *-pc-windows-gnullvm, I think the only reasonble "upstream" fix is for llvm-dlltool to pick up the additional options that rust is using. @mstorsjo said he was going to look at that. Once that is done, bootstrapping should be possible again, though it is still inefficient to call out to dlltool to get llvm to generate import libraries rather than just using llvm's apis to do so (which is what happens once that target check is hardcoded to false)

The eventual proper fix will be switching to -gnullvm for CLANG{64,32} (CLANGARM64 already is because there is no aarch64-pc-windows-gnu yet). The reasons that has not been done yet are:

1. At first, the crate ecosystem didn't know about -gnullvm and it took time for updates to work their way through so that packages were able to be able to be built for that target. With CLANGARM64 as a representative, it seems that that is pretty OK (except for now needing Avoid using unstable target abi feature microsoft/windows-rs#2515 to get released and work its way through)
2. @mati865 was talking about some llvm errors that needed to be tracked down. I didn't see them, so couldn't help there.
3. there is no i686-pc-windows-gnullvm (for CLANG32). This is because that was broken at the time the others were added. That should be added, and then unfortunately more time for 1 again.

[jeremyd2019]

I built a CLANG64 rust 1.70.0 targeting x86_64-pc-windows-gnullvm, I could upload the packages somewhere if anyone is interested in testing/playing around with it.

I uploaded to a 'test' release I had on my MINGW-packages fork. the tag it's pointing at has no relation to anything, it's just a place to put the files...
https://github.com/jeremyd2019/MINGW-packages/releases/download/test/mingw-w64-clang-x86_64-rust-1.70.0-2-any.pkg.tar.zst
and
https://github.com/jeremyd2019/MINGW-packages/releases/download/test/mingw-w64-clang-x86_64-rust-docs-1.70.0-2-any.pkg.tar.zst

[ognevny]

nevertheless, I can use RustPython compiled under pc-windows-gnu target

[jeremyd2019]

lld: error: unable to find library -lwindows.0.48.0

That's microsoft/windows-rs#2515. I've had to work around that plenty of times for aarch64-pc-windows-gnullvm. Example: 9040005

[ognevny]

That's microsoft/windows-rs#2515. I've had to work around that plenty of times for aarch64-pc-windows-gnullvm. Example: 9040005

I see. so how can I build RustPython then?

[jeremyd2019]

That's microsoft/windows-rs#2515. I've had to work around that plenty of times for aarch64-pc-windows-gnullvm. Example: 9040005

I see. so how can I build RustPython then?

🤷 My best guess was what I copied all over various packages here, as seen in 9040005: vendor the deps, and modify Cargo.toml in windows-targets.

[jeremyd2019]

windows-targets 0.48.1 was just released with the fix for gnullvm: microsoft/windows-rs#2558. Hopefully that should be easier. (I'm hoping as easy as something like cargo update -p windows-targets but I don't really know rust/cargo that well so that may not be the correct incantation)

[jeremyd2019]

I built x86_64-pc-windows-gnullvm variant of rust 1.77.0:

• https://github.com/jeremyd2019/MINGW-packages/releases/download/test/mingw-w64-clang-x86_64-rust-1.77.0-2-any.pkg.tar.zst
• https://github.com/jeremyd2019/MINGW-packages/releases/download/test/mingw-w64-clang-x86_64-rust-docs-1.77.0-2-any.pkg.tar.zst

I also built an i686/CLANG32 version, but windows-rs doesn't support i686-pc-windows-gnullvm, so it will probably not be very useful

• https://github.com/jeremyd2019/MINGW-packages/releases/download/test/mingw-w64-clang-i686-rust-1.77.0-2-any.pkg.tar.zst

[TheRustifyer]

@jeremyd2019

I try to stablish my setup on a llvm/clang/lld toolchain. I tought that the correct way would be to use the clang64 environment.
What I typically do, is to invoke from my terminal emulator the env like this:

C:/msys64/msys2_shell.cmd -defterm -here -no-start -clang64 -use-full-path -shell zsh

I have clang64 and mingw64 bin paths on PATH, as well as /usr/bin and /usr/local/bin.

• I tried to build the full llvm-suite following their docs, but fails due to ld.lld linker errors.
• I tried to build a simpleRust project. Ex: cargo new hello && cd hello/ && cargo build. Fails due to the typical lgcc missing error.

I just wanted to know if even any of what I told you here makes sense. Probably I am missconfiguring things, and receiving weird errors due to my lack of knowledge.

Building C++ modules projects and Rust projects are my main goals.
But first things first.

• Does makes sense to try to use the clang64 env at all? I included the gcc-compat package, but doesn't seems to work
• Should I wait for the gnullvm toolchain? Even tho, is third class support as per the cargo docs
• I would really like to be able to use libc++ based enviroments, that's my point.

NOTE: I don't use any of the MSYS2 packages. I install Rust with rustup targeting the GNU ABI. Maybe that's another missconfiguration point.

Will you guide me just a little bit of how I should configure my Rust + C++ environments using MSYS2 in the proper way?

Thanks beforehand.@jeremyd2019 quick doubt.

I try to stablish my setup on a llvm/clang/lld toolchain. I tought that the correct way would be to use the clang64 environment.
What I typically do, is to invoke from my terminal emulator the env like this:

C:/msys64/msys2_shell.cmd -defterm -here -no-start -clang64 -use-full-path -shell zsh

I have clang64 and mingw64 bin paths on PATH, as well as /usr/bin and /usr/local/bin.

• I tried to build the full llvm-suite following their docs, but fails due to ld.lld linker errors.
• I tried to build a simpleRust project. Ex: cargo new hello && cd hello/ && cargo build. Fails due to the typical lgcc missing error.

I just wanted to know if even any of what I told you here makes sense. Probably I am missconfiguring things, and receiving weird errors due to my lack of knowledge.

Building C++ modules projects and Rust projects are my main goals.
But first things first.

• Does makes sense to try to use the clang64 env at all? I included the gcc-compat package, but doesn't seems to work
• Should I wait for the gnullvm toolchain? Even tho, is third class support as per the cargo docs
• I would really like to be able to use libc++ based enviroments, that's my point.

NOTE: I don't use any of the MSYS2 packages. I install Rust with rustup targeting the GNU ABI. Maybe that's another missconfiguration point.

Will you guide me just a little bit of how I should configure my Rust + C++ environments using MSYS2 in the proper way?

Thanks beforehand.

[mati865]

• I tried to build the full llvm-suite following their docs, but fails due to ld.lld linker errors.

LLVM testsuite doesn't fully support Windows yet.

• I tried to build a simpleRust project. Ex: cargo new hello && cd hello/ && cargo build. Fails due to the typical lgcc missing error.

You need *-gnullvm target or patched toolchain (like Rust from CLANG* envs).

Building C++ modules projects and Rust projects are my main goals.

There is no C++ modules support yet, Martin has patched mingw-w64 recently but LLVM is still WIP: mstorsjo/llvm-mingw#425

• Should I wait for the gnullvm toolchain? Even tho, is third class support as per the cargo docs

Already tier 2 (without host tools) on nightly, within a few days also in beta.

NOTE: I don't use any of the MSYS2 packages. I install Rust with rustup targeting the GNU ABI. Maybe that's another missconfiguration point.

With rustup you need to use nightly toolchain (or beta in a few days) and target x86_64-pc-windows-gnullvm.

[TheRustifyer]

@mati865 thanks for your detailed response!

[jeremyd2019]

I made a workflow to build gnullvm rust in 3 steps. Before, CLANG32 was failing building step 2. Today, with 1.79.0, it failed trying to build bootstrap in step 3. I consider this a good sign, that things that depend on the versions of windows-targets that were broken for i686-pc-windows-gnullvm are fewer, and probably once bootstrap (or whatever transitive dependency) is updated I'll be able to build an i686-pc-windows-gnullvm rustc without special hacks.

In the meantime, https://github.com/jeremyd2019/msys2-rust-gnullvm/releases/tag/1.79.0-2 has the x86_64. In future I'll try to run that workflow, which makes a new release, on rust updates, and hopefully in 1.80.0 i686 will show up there too.

[jeremyd2019]

It looks like src/bootstrap just needs a cargo update, specifically just cargo update windows-targets --precise 0.52.5 does the trick. Hopefully they do that as part of the release/branching process for 1.80.0

[jeremyd2019]

It looks like src/bootstrap just needs a cargo update, specifically just cargo update windows-targets --precise 0.52.5 does the trick. Hopefully they do that as part of the release/branching process for 1.80.0

It appears they didn't (and still haven't). @mati865 would you do a pull request on rust? Or should I try?

UPDATE: nevermind, it was done in rust-lang/rust@f449586, says milestone 1.82.0 on the pr

[mati865]

Yes, updates are not automated yet and usually occur when there is a particular need for them.

[jeremyd2019]

I believe this is done now, so I'm closing this discussion. I'll archive my github repo and delete it at some point in the future