Build failure on Windows UWP target (aarch64-uwp-windows-msvc, x86_64-uwp-windows-msvc, i686-uwp-windows-msvc)

[Darkspirit]

Log: https://github.com/servo/servo/pull/26005#issuecomment-602590931

[Darkspirit]

x86_64-uwp-windows-msvc was successful. aarch64 windows is missing in https://github.com/briansmith/ring/blob/ddfa683266e8ce41c06feb9f46503dd4e1d47ab1/build.rs#L230-L242.

[briansmith]

I'm happy to add this. I don't know how to do the test automation for UWP targets. Any ideas?

[Darkspirit]

This is what I've found about AppVeyor: It seems Visual Studio 2017 or 2019 are required for arm64 support. The Rust project cross-compiles to aarch64-pc-windows-msvc for testing. https://help.appveyor.com/discussions/questions/27382-arm64-support-in-the-default-image https://github.com/rust-lang/rust/pull/54718/files If desired, multiple images could be configured and arm64 be restricted to 2017: https://github.com/erthink/libfpta/blob/2f866f265683d9b93eb032b822a1b8f6373a7f13/externals/t1ha/.appveyor.yml This is how other projects configured AppVeyor with arm64: https://github.com/search?q=arm64++filename%3A.appveyor.yml&type=Code&ref=advsearch&l=&l=

[briansmith]

It is fine to require VS 2017 or VS 2019 as the minimum version.

My question though is, after we built for, say, aarch64-uwp-windows-msvc, how do we actually run the tests on that plaform?

[briansmith]

My question though is, after we built for, say, aarch64-uwp-windows-msvc, how do we actually run the tests on that plaform?

...on a x86-64-pc-windows-msvc host.

[sumibi-yakitori]

Hello @briansmith I want to build this library to the aarch64-uwp-windows-msvc target to use your library with HoloLens2.

I'm not familiar with Rust's build system. Can't we use xargo test for automated tests?

[sumibi-yakitori]

I tried working on the aarch64-uwp-windows-msvc build, but the yasm and nasm do not support Arm architecture...

[briansmith]

I tried working on the aarch64-uwp-windows-msvc build, but the yasm and nasm do not support Arm architecture...

Right now, build.rs says "if we're on windows, use yasm or nasm." Instead it needs to say "if we're targetting x86-64 or x86-64 on windows, use yasm or nasm."

[briansmith]

I tried working on the aarch64-uwp-windows-msvc build,

Check out https://boringssl.googlesource.com/boringssl/+/bc7e2cb92d948de5f437e5eef2b1c3ad6281bb35. That's basically what we'll need to do to get it working, on top of adjusting the build system.

[sumibi-yakitori]

@briansmith Thank you so much! I'll look into it.

[briansmith]

How are you even installing the rust toolchain for x86_64-uwp-windows-msvc, i686-uwp-windows-msvc, and aarch64-uwp-windows-msvc? I.e. what is the equivalent of rustup target add x86_64-uwp-windows-msvc that you are doing?

The code change is very small, but I can't even test it without being able to install the toolchain.

[sumibi-yakitori]

I couldn't install the aarch64-uwp-windows-msvc and i686-uwp-windows-msvc toolchains in my environment with rustup or cargo, so I'm using xargo to install it.

rustup default nightly
cargo install xargo
rustup component add rust-src
xargo update
xargo build --target aarch64-uwp-windows-msvc
xargo build --target i686-uwp-windows-msvc

The DLL built this way (without ring) is now functional under my HoloLen2(Arm64+UWP) and HoloLens1(x86+UWP) environments.

My xargo.toml

[dependencies.std]
features = ["panic_unwind", "std_detect_dlsym_getauxval", "std_detect_file_io"]

[briansmith]

Is anybody actually using Rust on UWP?

• I see that even now UWP targets aren't available using rustup and the response to the request at https://github.com/rust-lang/rustup/issues/2379 indicates to me that nobody from the Rust side even cares about UWP.
• Further, libstd was broken for almost 2 months; see https://github.com/rust-lang/rust/issues/79203. AFAICT the only way to target UWP is to use Nightly and Xargo or a custom build, so if people didn't notice libstd was broken for two months, there must be very few people who care.
• It seems like if Microsoft wanted UWP to still be a thing, they would invest resources into UWP, but I don't see any evidence of that.
• https://www.thurrott.com/dev/206351/microsoft-confirms-uwp-is-not-the-future-of-windows-apps and https://www.theverge.com/2020/5/19/21258697/microsoft-windows-project-reunion-win32-uwp-apps-apis-build make it seem like there's no future in targeting UWP separately from normal Windows targets.

Am I missing something?

[briansmith]

I tried using xargo build --target=x86_64-uwp-windows-msvc using cargo 1.50.0-nightly (bfca1cd22 2020-11-24) but it failed with:

87 | extern crate alloc;
   | ^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error```

[sumibi-yakitori]

@briansmith

The time I had to keep up with the stale UWP was over in June of this year. As far as my personal problems are concerned, I don't need UWP support anymore. Sorry for wasting your time.

[Darkspirit]

Is anybody actually using Rust on UWP?

It might only be Servo, I don't know. In https://github.com/servo/servo/issues/27848 the intention/desire is stated to keep the UWP/Hololens port alive. It can also be used on Win10 desktop. Unfortunately, the winit port of Servo (regular Linux, Mac, Windows app) is still a bit lagging behind in terms of basic UI elements. I don't know if they would abandon the UWP/Hololens port when the winit port finally gets UI elements, given that they have worked so much on UWP. The main focus still seems to be on others embedding the Servo engine instead of also becoming a web browser of its own. Given the mass of code I doubt Servo's team would accept rustls if openssl had to be kept for UWP.

---

make it seem like there's no future in targeting UWP separately from normal Windows targets.

If there is a new/better way of creating Hololens apps, we should file a Servo issue, but I have found this comment: Quote from https://github.com/microsoft/ProjectReunion/issues/301#issuecomment-733087616:

Here is my current understanding based on following the Project Reunion repository: You shouldn't expect support for your Win32 app (using Project Reunion APIs or not) to run (natively) on all the other Windows device categories any time soon, nor is there a guarantee that such support will come at all in the future. @\ptorr-msft gave such a comment here. If you need to deploy your app or run it natively/"best" on Windows devices like the Xbox, HoloLens, Surface Hub, IoT, potentially 10X (let's wait and see how the 10X story will unfold), then a UWP app is the way to go.

---

Servo compiles everything with Rust nightly (currently nightly-2020-07-27), and uses xargo for UWP. https://github.com/servo/servo/search?l=Python&q=uwp https://github.com/servo/servo/search?q=xargo

87 | extern crate alloc; | ^^^^^^^^^^^^^^^^^^^ can't find crate

https://github.com/japaric/xargo/issues/110 says it would mean a Xargo.toml file is missing. https://github.com/servo/servo/blob/master/Xargo.toml UWP also runs rustup component add rust-src.

[briansmith]

@sumibi-yakitori Thanks for the update.

@Darkspirit Thanks for the very useful info.

Servo compiles everything with Rust nightly (currently nightly-2020-07-27), and uses xargo for UWP.

Thanks. nightly-2020-07-27 is quite old. I wonder why they're using such an old version? Perhaps just because of the organizational changes?

In any case, there are other reason why I need to make the changes that would likely be prerequisites for UWP support, so I'll make those changes and then report back here when they are done. Then perhaps somebody could help with the UWP-specific bits.

It would be great if somebody could verify that a very recent version of Rust Nightly (2020-11-29 or later) works with Xargo for the UWP target.

[briansmith]

In https://github.com/briansmith/ring/issues/1193#issuecomment-786536170, @bdbai shared this log: https://gist.github.com/bdbai/ff93935e702407bc3125a79ae28b4e31 when building for "thumbv7a-uwp-windows-msvc"

@bdbai Could you please tell me how to get a working rust toolchain that can build "hello world" for thumbv7a-uwp-windows-msvc? From there I will be able to help you.

[bdbai]

Since UWP targets are in Tier 3, rustup does not provide prebuilt artifacts for them. My solution is to use the std Aware feature of Cargo. In a Developer Command Prompt for Visual Studio, navigate to a workspace and build using the following command

cargo +nightly build -Z build-std=std,panic_abort --target thumbv7a-uwp-windows-msvc

Cargo will automatically build the standard libraries for that target first, followed by other crates. Another option is Xargo, which basically does the same thing.

[bdbai]

I have tried out ring version 0.17.0-alpha.10 with the thumbv7a UWP target. The first problem is a compiler error C4146 on this line:

https://github.com/briansmith/ring/blob/fe67830da183a3254b0a9da179631f1c9631d2f7/crypto/poly1305/poly1305_arm.c#L79

After fixing this, I got a bunch of unresolved symbols, like ring_core_0_17_0_alpha_10_x25519_NEON and ring_core_0_17_0_alpha_10_ChaCha20_ctr32 etc. I guess it is because the build script does not recognize this target as an ASM_TARGET, while the fallback is also excluded:

https://github.com/briansmith/ring/blob/fe67830da183a3254b0a9da179631f1c9631d2f7/src/aead/chacha.rs#L138-L144

[briansmith]

I have tried out ring version 0.17.0-alpha.10 with the thumbv7a UWP target. The first problem is a compiler error C4146 on this line:

Please try the newest version of ring 0.17.0 and/or the latest main branch and report back.

Also, my understanding from a quick Google is that UWP is dead? Please comment back if that's not the case and I'll reopen this.

[bdbai]

Also, my understanding from a quick Google is that UWP is dead? Please comment back if that's not the case and I'll reopen this.

According to Windows app development: options and features as of updated on 10/13/2023, UWP is still a "Currently supported" development option.

[briansmith]

The first problem is a compiler error C4146 on this line:

The C code for AAarch64/ARM has been written to only work with GCC/Clang/etc. It probably needs very minor tweaks to work with MSVC. And/or you could set TARGET_CC to build with Clang. MS Visual Studio (Build Tools) includes clang as as an optional component. Look at the BUILDING.md instructions for aarch64-pc-windows-msvc, where we only presently support clang as the C compiler.

I got a bunch of unresolved symbols, like ring_core_0_17_0_alpha_10_x25519_NEON and ring_core_0_17_0_alpha_10_ChaCha20_ctr32 etc. I guess it is because the build script does not recognize this target as an ASM_TARGET, while the fallback is also excluded:

Yes, the build.rs probably needs to be updated to consider this target. I would accept PRs for this.

[briansmith]

The first problem is a compiler error C4146 on this line:

C4146 is a warning, but we treat warnings as errors when you're building from a Git checkout. Please see build.rs where we disable other warnings. Just make a PR that adds C4146 to the list.

[bdbai]

Yes, the build.rs probably needs to be updated to consider this target.

I tried to tweak the build script to include ARM 32 on Windows (see this commit https://github.com/YtFlow/ring/commit/5f8b03c8209f85c69b4f8f2c6d1ef4b325d2ff62), it still failed with unresovled symbols:

Any ideas why it could go wrong? Or shall we just use fallback implementations for this case instead?

[briansmith]

Regarding C4163: '_addcarry_u32': not available as an intrinsic function and similar warnings about intrinsics:

#if defined(_MSC_VER) && !defined(__clang__)
#pragma warning(push, 3)
#include <intrin.h>
#pragma warning(pop)

[briansmith]

Regarding "/wd4068", // C4068: unknown pragma 'GCC', you need to wrap the #pragma GCC in #if; see other places in the code base.

[briansmith]

AsmTarget {
       oss: &[WINDOWS],
       arch: "arm"

You need to change the "aarch64" AsmTarget, not the arm one. You aren't trying to do anything with 32-bit ARM, right? At least, according to the subject of this issue.

[bdbai]

You aren't trying to do anything with 32-bit ARM, right?

Actually, I was specifically working on the thumbv7a-uwp-windows-msvc target. Initially the problem was raised in this issue, then I was directed here.

At least, according to the subject of this issue.

At the time of this issue being created, the thumbv7a-uwp-windows-msvc target was not added to Rust. I think that is why it is not mentioned in the subject.

[briansmith]

Actually, I was specifically working on the thumbv7a-uwp-windows-msvc target. Initially the problem was raised in https://github.com/briansmith/ring/issues/1193#issuecomment-786536170, then I was directed here.

According to https://github.com/rust-lang/rust/issues/109030, there is no plans for the Rust toolchain to support that target.

I suggest we focus on verifying that x86_64-uwp-windows-msvc works first, then aarch64-uwp-windows-msvc.

For 32-BIT ARM Windows (!?!?!), you'd probably need to force the use of clang like we do for aarch64-pc-windows-msvc, and/or change build.rs to use cc_asm to assemble the assembly language code. And that's what I'd recommend doing for aarch64-uwp-windows-msvc too.