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

Darkspirit · 2020-03-23T14:49:51Z

Darkspirit · 2020-03-23T16:26:20Z

x86_64-uwp-windows-msvc was successful.
aarch64 windows is missing in

Lines 230 to 242 in ddfa683

    
           const ASM_TARGETS: &[(&str, Option<&str>, &str)] = &[ 
        
               ("x86_64", Some("ios"), "macosx"), 
        
               ("x86_64", Some("macos"), "macosx"), 
        
               ("x86_64", Some(WINDOWS), "nasm"), 
        
               ("x86_64", None, "elf"), 
        
               ("aarch64", Some("ios"), "ios64"), 
        
               ("aarch64", None, "linux64"), 
        
               ("x86", Some(WINDOWS), "win32n"), 
        
               ("x86", Some("ios"), "macosx"), 
        
               ("x86", None, "elf"), 
        
               ("arm", Some("ios"), "ios32"), 
        
               ("arm", None, "linux32"), 
        
           ];

.

briansmith · 2020-03-24T17:02:38Z

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

Darkspirit · 2020-03-24T19:30:19Z

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 · 2020-03-27T16:22:56Z

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 · 2020-03-27T16:23:17Z

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 · 2020-05-25T17:29:58Z

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 · 2020-05-25T19:32:15Z

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

briansmith · 2020-05-25T19:34:46Z

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 · 2020-05-25T19:36:30Z

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 · 2020-05-25T19:42:48Z

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

briansmith · 2020-06-02T16:02:14Z

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.

…UWP app. This is tracked by #960.

sumibi-yakitori · 2020-06-03T00:05:10Z

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 · 2020-11-27T04:34:19Z

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 Add support for uwp Windows targets rust-lang/rustup#2379 indicates to me that nobody from the Rust side even cares about UWP.
Further, libstd was broken for almost 2 months; see UWP standard library no longer builds rust-lang/rust#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 · 2020-11-27T04:36:41Z

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 · 2020-11-27T08:47:43Z

@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 · 2020-11-27T09:51:39Z

Is anybody actually using Rust on UWP?

It might only be Servo, I don't know. In servo/servo#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 microsoft/WindowsAppSDK#301 (comment):

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

japaric/xargo#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 · 2020-11-30T08:20:36Z

@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 · 2021-02-26T19:20:23Z

In #1193 (comment), @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 · 2021-02-27T00:44:00Z

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 · 2021-08-07T15:11:10Z

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:

ring/crypto/poly1305/poly1305_arm.c

Line 79 in fe67830

swap = -(y4 >> 26);

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:

ring/src/aead/chacha.rs

Lines 138 to 144 in fe67830

    
                   #[cfg(not(any( 
        
                       target_arch = "aarch64", 
        
                       target_arch = "arm", 
        
                       target_arch = "x86", 
        
                       target_arch = "x86_64" 
        
                   )))] 
        
                   use fallback::ChaCha20_ctr32;

briansmith · 2023-10-14T03:57:32Z

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 · 2023-10-14T04:05:00Z

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 · 2023-10-14T04:09:53Z

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 · 2023-10-14T04:11:15Z

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 · 2023-10-15T14:13:02Z

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 YtFlow@5f8b03c), 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 · 2023-10-15T15:42:00Z

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 · 2023-10-15T15:42:48Z

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

briansmith · 2023-10-15T15:47:41Z

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 · 2023-10-15T16:50:45Z

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 · 2023-10-15T21:40:41Z

Actually, I was specifically working on the thumbv7a-uwp-windows-msvc target. Initially the problem was raised in #1193 (comment), then I was directed here.

According to rust-lang/rust#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.

Darkspirit mentioned this issue Mar 23, 2020

Replace ring with sha2. rust-ammonia/rust-content-security-policy#28

Merged

briansmith changed the title ~~Build failure on Windows UWP target (aarch64-uwp-windows-msvc)~~ Build failure on Windows UWP target (aarch64-uwp-windows-msvc, x86_64-uwp-windows-msvc, i686-uwp-windows-msvc) Jun 2, 2020

briansmith added a commit that referenced this issue Jun 2, 2020

Skip BoringSSL bc7e2cb: Use BCryptGenRandom when building as Windows …

ac46ade

…UWP app. This is tracked by #960.

museun mentioned this issue Jun 4, 2020

Rework target matrix museun/twitchchat#132

Merged

Darkspirit mentioned this issue Aug 4, 2020

Delegating crypto to a RustCrypto traits implementation rustls/rustls#390

Closed

Alovchin91 mentioned this issue Jan 5, 2021

Windows arm64 support (aarch64-pc-windows-msvc) #1167

Closed

briansmith mentioned this issue Feb 26, 2021

cargo build --release --target=aarch64-linux-android error: ring-0.16.20/pregenerated/aesv8-armx-linux64.S"]: No such file or directory (os error 2) #1193

Closed

briansmith closed this as not planned Won't fix, can't repro, duplicate, stale Oct 14, 2023

briansmith reopened this Oct 14, 2023

bdbai mentioned this issue Oct 22, 2023

Add Windows ARM32 (thumbv7a-pc-windows-msvc/thumbv7a-uwp-windows-msvc) support #1767

Open

briansmith closed this as not planned Won't fix, can't repro, duplicate, stale Feb 25, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Darkspirit commented Mar 23, 2020

Darkspirit commented Mar 23, 2020

briansmith commented Mar 24, 2020

Darkspirit commented Mar 24, 2020

briansmith commented Mar 27, 2020

briansmith commented Mar 27, 2020

sumibi-yakitori commented May 25, 2020 •

edited

Loading

sumibi-yakitori commented May 25, 2020 •

edited

Loading

briansmith commented May 25, 2020

briansmith commented May 25, 2020

sumibi-yakitori commented May 25, 2020

briansmith commented Jun 2, 2020 •

edited

Loading

sumibi-yakitori commented Jun 3, 2020 •

edited

Loading

briansmith commented Nov 27, 2020

briansmith commented Nov 27, 2020 •

edited

Loading

sumibi-yakitori commented Nov 27, 2020

Darkspirit commented Nov 27, 2020

briansmith commented Nov 30, 2020

briansmith commented Feb 26, 2021

bdbai commented Feb 27, 2021

bdbai commented Aug 7, 2021

briansmith commented Oct 14, 2023

bdbai commented Oct 14, 2023 •

edited

Loading

briansmith commented Oct 14, 2023

briansmith commented Oct 14, 2023

bdbai commented Oct 15, 2023

briansmith commented Oct 15, 2023

briansmith commented Oct 15, 2023

briansmith commented Oct 15, 2023

bdbai commented Oct 15, 2023

briansmith commented Oct 15, 2023

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

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

Comments

Darkspirit commented Mar 23, 2020

Darkspirit commented Mar 23, 2020

briansmith commented Mar 24, 2020

Darkspirit commented Mar 24, 2020

briansmith commented Mar 27, 2020

briansmith commented Mar 27, 2020

sumibi-yakitori commented May 25, 2020 • edited Loading

sumibi-yakitori commented May 25, 2020 • edited Loading

briansmith commented May 25, 2020

briansmith commented May 25, 2020

sumibi-yakitori commented May 25, 2020

briansmith commented Jun 2, 2020 • edited Loading

sumibi-yakitori commented Jun 3, 2020 • edited Loading

briansmith commented Nov 27, 2020

briansmith commented Nov 27, 2020 • edited Loading

sumibi-yakitori commented Nov 27, 2020

Darkspirit commented Nov 27, 2020

briansmith commented Nov 30, 2020

briansmith commented Feb 26, 2021

bdbai commented Feb 27, 2021

bdbai commented Aug 7, 2021

briansmith commented Oct 14, 2023

bdbai commented Oct 14, 2023 • edited Loading

briansmith commented Oct 14, 2023

briansmith commented Oct 14, 2023

bdbai commented Oct 15, 2023

briansmith commented Oct 15, 2023

briansmith commented Oct 15, 2023

briansmith commented Oct 15, 2023

bdbai commented Oct 15, 2023

briansmith commented Oct 15, 2023

sumibi-yakitori commented May 25, 2020 •

edited

Loading

sumibi-yakitori commented May 25, 2020 •

edited

Loading

briansmith commented Jun 2, 2020 •

edited

Loading

sumibi-yakitori commented Jun 3, 2020 •

edited

Loading

briansmith commented Nov 27, 2020 •

edited

Loading

bdbai commented Oct 14, 2023 •

edited

Loading