contrib: rust: enable more Rust targets
Based on https://doc.rust-lang.org/nightly/rustc/platform-support.html
- UCRT Windows targets
-
aarch64 Windows target (UCRT only)doesn't work https://code.videolan.org/robUx4/vlc/-/jobs/1829048 - macOS aarch64
Merge request reports
Activity
changed milestone to %4.0
added MRStatus::NotCompliant label
Weird
. /builds/robUx4/vlc/contrib/bin/.cargo/env && RUSTUP_HOME=/builds/robUx4/vlc/contrib/bin/.rustup CARGO_HOME=/builds/robUx4/vlc/contrib/bin/.cargo rustup target add aarch64-pc-windows-gnullvm error: toolchain '1.75.0-x86_64-unknown-linux-gnu' does not support target 'aarch64-pc-windows-gnullvm' note: you can see a list of supported targets with `rustc --print=target-list` note: if you are adding support for a new target to rustc itself, see https://rustc-dev-guide.rust-lang.org/building/new-target.html
When I run it locally with the same rust from contribs:
$ . ./contrib/bin/.cargo/env && RUSTUP_HOME=/mnt/s/sources/build/win64-llvm18/contrib/bin/.rustup CARGO_HOME=/mnt/s/sources/build/win64-llvm18/contrib/bin/.cargo rustc --print=target-list | grep aarch64-pc-windows-gnullvm aarch64-pc-windows-gnullvm
Maybe it depends on the version of the LLVM used to build rust ???Edited by Steve LhommePrebuilt gnullvm targets are only available in Rust 1.79+. If it works somewhere, then Rust 1.79+ had been used. PRs that added prebuilt binaries: https://github.com/rust-lang/rust/pull/121712 https://github.com/rust-lang/rust/pull/124229
added 33 commits
-
f66c85b2...fe26ba9b - 30 commits from branch
videolan:master
- 43fae836 - contrib: rust: enable aarch64-apple-darwin
- b607993b - contrib: detect Windows build with UCRT instead of msvcrt
- ae815ff7 - contrib: rust: use the "llvm" targets when building with UCRT
Toggle commit list-
f66c85b2...fe26ba9b - 30 commits from branch
added MRStatus::Reviewable label and removed MRStatus::NotCompliant label
added MRStatus::Accepted label and removed MRStatus::Reviewable label
MR Acceptance result
This MergeRequest has been Accepted! Congratulations.MR acceptance checks details:
-
MR should be considered mergeable by Gitlab -
Last pipeline should be successful -
No activity on MR (no thread, no vote) and last update is long enough
-
added 10 commits
-
ae815ff7...d360da6b - 7 commits from branch
videolan:master
- 452d735a - contrib: rust: enable aarch64-apple-darwin
- 872169c2 - contrib: detect Windows build with UCRT instead of msvcrt
- 3db7c594 - contrib: rust: use the "llvm" targets when building with UCRT
Toggle commit list-
ae815ff7...d360da6b - 7 commits from branch
enabled an automatic merge when the pipeline for 3db7c594 succeeds
- Resolved by Martin Storsjö
4 4 # This file is under the same license as the vlc package. 5 5 6 6 ifdef HAVE_WIN32 7 ifndef HAVE_WINSTORE 7 ifdef HAVE_UCRT 8 ifndef HAVE_WINSTORE # UWP is available as Tier 3 9 ifeq ($(HOST),i686-w64-mingw32) 10 RUST_TARGET = i686-pc-windows-gnullvm # ARCH is i386 Commenting on the commit message here ("The naming in Rust is bogus but it does means it's using UCRT") - I wouldn't say it's bogus, but it combines multiple things. A GCC toolchain using UCRT probably shouldn't use the
-gnullvm
targets. So I think the naming is mostly reasonable, the-gnu
vs-gnullvm
is primarily about tool type, but they also have the-gnullvm
targets to imply UCRT.Hey, I'm the
-windows-gnullvm
target maintainer. Martin is right,gnullvm
targets most importantly use LLVM libraries and ABI. So libgcc is replaced with libunwind, the linker is LLD, it uses native TLS instead of emutls, function sections are enabled, and there's probably something else that I forgot. UCRT is another difference, but a smaller one since the changes from my previous sentence cause builds with GCC/Binutils to break.windows-gnu
targets are built with MSVCRT, but that shouldn't be a big deal as long as you stick to the default static std library (in other words, as long as you don't use-C prefer-dynamic
). I can't guarantee it will always work, but it's much better compared to usingwindows-gnullvm
targets, which have a 100% chance of failing when using them with GCC/Binutils. Unless you want to migrate to LLVM as well (windows-gnullvm
targets by default will pick Clang from PATH as the linker), but that would be a much bigger change than this PR implies.Thanks for the tips. Maybe it should only be used with
HAVE_CLANG
then (which we already test) for better safety.We do plan to make the VLC 4 Windows builds with LLVM but there's very little Rust code in it yet. In that scenario every library is compiled with the same LLVM and we even build our compiler from scratch.
BTW since v12 mingw-w64 defaults to UCRT: https://github.com/mingw-w64/mingw-w64/commit/82b8edc101d7f8fefd44e84d2e24a6edd01901f9
Yes but due to various issues in GCC/Binutils and lack of build with Binutils 2.40+ at https://github.com/niXman/mingw-builds-binaries/releases?page=1 Rust is still using mingw-w64 from 2 years ago.
mentioned in merge request !5803 (merged)