8000 Add native Windows Arm64 support · Issue #1395 · helgoboss/helgobox · GitHub
[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add native Windows Arm64 support #1395

Open
helgoboss opened this issue Jan 2, 2025 · 2 comments
Open

Add native Windows Arm64 support #1395

helgoboss opened this issue Jan 2, 2025 · 2 comments
Labels
enhancement New feature or request windows Happens on Microsoft Windows

Comments

@helgoboss
Copy link
Owner

No description provided.

@helgoboss helgoboss added enhancement New feature or request windows Happens on Microsoft Windows labels Jan 2, 2025
@helgoboss helgoboss added this to the 2.19.0 milestone Jan 2, 2025
helgoboss added a commit that referenced this issue Jan 2, 2025
@helgoboss
#1395 Fix Windows Arm64 build part 1
57f3276
helgoboss added a commit that referenced this issue Jan 3, 2025
@helgoboss
#1395 Link arm64ec version of EEL
5c983d1
helgoboss added a commit that referenced this issue Jan 3, 2025
@helgoboss
#1395 Use target_arch arm64ec also for Pot Browser
9a9911a
@helgoboss
Copy link
Owner Author
helgoboss commented Jan 3, 2025 •
edited
Loading

Building for Windows ARM64 requires build with cargo build --target arm64ec-pc-windows-msvc, even when running Rust on ARM64 windows with the toolchain stable-aarch64-pc-windows-msvc. Otherwise the arm64ec version of the EEL assembly code will not link. And even without that nuisance, an aarch64 binary probably wouldn't work within REAPER arm64ec (because AFAIK an application built for arm64ec can only load x64 or arm64ec libraries, not aarch64/arm64 ones).

Building for arm64ec leads to target_arch being arm64ec instead of aarch64. This currently leads to failures when building win-api and windows-sys crates. I think we need to update to a recent version of windows-sys (at least 0.59.0). And maybe try to get rid of win-api, since it is not maintained anymore. As soon as this is done, let's see what else pops up.

helgoboss added a commit that referenced this issue Jan 16, 2025
@helgoboss
#1395 Remove one unnecessary reference to windows-sys crate
671795f
helgoboss added a commit that referenced this issue Jan 16, 2025
@helgoboss
#1395 Update to latest public mlua
b746e7c
helgoboss added a commit that referenced this issue Jan 16, 2025
@helgoboss
#1395 Fix build errors caused by new mlua
25b5497
@helgoboss
Copy link
Owner Author

The issue with windows-sys is that a bunch of dependencies depend on older versions (namely 0.48.0 and 0.52.0). Since those older versions all start with 0, each change in the minor version is considered a breaking change, so cargo update windows-sys won't do anything. I think we need to actively fork those dependencies and maybe send PRs.

@helgoboss helgoboss removed this from the 2.18.0 milestone Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request windows Happens on Microsoft Windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@helgoboss
0