Ring: 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.