Request Porting for Windows 11 arm64

[ronaldomier]

Please port Perl to Windows arm64 for native support.

[simcop2387]

This is being looked into and worked on, the largest blocker is that MSYS2 does not support arm64 windows yet. I've got a system built to work on this and will update this later with links to the msys2 github issues related to this. Once we can get the MSYS2 libraries working on arm64 we should be able to start getting some preliminary builds going. not sure when that will be yet though. Until then you might be able to get the amd64 builds running under the built in emulation in windows

[simcop2387]

forgot to mention this would be trying to support win 10 and above. while 8 and 8.1 for arm exist too, i don't have a way to test or try to support them. 10 has official support on some surface devices so it seems like a reasonable spot to start support. if i get it working on 10 it should work on 11 and i'll likely try to get an actual device running 11 for testing too

[pbo-linaro]

@simcop2387: Is MSYS2 a mandatory requirement? Could it be built using msvc instead?

[genio]

@pbo-linaro Unfortunately, no. Given the nature of Perl, XS modules require a compiler. Since MSVC requires licensing for any use that's not personal, it would force users of Perl to license MSVC in order to have any XS modules installed.

[genio]

We have requested that they make a change for that, but we likely won't get anywhere with it anytime soon: https://developercommunity.visualstudio.com/t/CC-compiler-and-linker-free-CLI-only/10042178

[pbo-linaro]

Yes, a change on that side won't happen soon, but thanks for requesting it.

Concerning MSYS2, is it only used for its compiler, or for other utilities as well?

Thanks to Linaro's and others effort (https://www.linaro.org/news/linaro-arm-and-qualcomm-collaborate-to-enable-native-llvm-for-windows-10-on-arm/), clang is now available natively for windows on arm here. With x64 emulation (available from win11) and native clang, could that be possible to port strawberry perl?

[genio]

Given that some libraries we use don't really have a way to easily build for Windows, we use MSYS2+MinGW for a build environment. It's an extremely complex problem that luckily kmx worked hard on and made as simple as he could with Strawberry Perl.

Using libraries built with MSVC by an executable built with MSYS2+MinGW/Clang gets messy. So, we have to build each and every library (more or less) with the same build environment that Perl was built with. This is why Strawberry Perl generally ships with things that aren't necessary for Perl itself (it ships with the MySQL client, etc.).

To further the problem, we have to keep the same version of MSYS2+MinGW the exact same for a given release of Perl. We can't upgrade any of the environment for a release of Perl. It complicates things a lot. If I build Strawberry Perl 5.10.1.0 with MSYS2 vX and MinGW vY I can't upgrade anything with the compiler or the set of libraries released with Perl if I need to release Strawberry Perl 5.10.1.1. Any XS module installed would then be broken. It gets chaotic pretty quickly.

That means we have to hold onto a ton of binaries we've built over the years for each version of Strawberry Perl and so on and so forth. It's... a lot.

[pbo-linaro]

Thanks for explaining this, that helps to understand content of Strawberry Perl.

From what I saw, 32 & 64 bits packages and description are already in different files. Would that make sense to define new variant for all this (built using clang?), like an arm64 version and description for external libs.

At Linaro, we are willing to help on this effort (developer time + provide an arm64 build machine). So far, we enabled native build (using msvc) for Perl and fixed a test to pass testsuite for Windows on Arm64. A natural continuation of this work is to help enable Strawberry Perl 😀

[genio]

@pbo-linaro We'd be happy for any help others can provide. Please keep us updated on any progress. I fear this one will be stuck for a while since MSYS2 isn't yet available on ARM64 Windows though.

[pbo-linaro]

@genio : I'm currently trying to build external libs. Do you build all versions (2022Q2, ..., 2019Q2) everytime or only some?

My current strategy is to fake "gcc" presence by linking clang instead. It works for some libraries, fail for some others. Would that be acceptable to get a partial support for windows on arm (if some are too complicated to build)?

[pbo-linaro]

FYI, someone at Linaro started to work officially on Windows on Arm support for gcc. It should not be completed soon, but at least we can expect it for 2023. We decided to postpone current efforts to use clang to compile strawberry perl for this platform.

For people interested, you can (from perl 5.36) compile it easily for windows on arm. We offer a precompiled version of it, including those cpan packages. Details for compilation can be found here. Note: This is not a complete distribution like strawberry (no compiler/libraries included), but you can use it as a starting point.

[genio]

@pbo-linaro Apologies. I just saw the question about the external libs. No, you do not need to build each one. You do, however, need to keep the libraries and compiler the exact same for a given release of Perl.

[hmartinez82]

MSYS2 runs on ARM64 now. I just build aria2c in my Surface Pro X in Windows 11 using a native build of Clang's, using its GCC frontend.

• Install MSYS2 (MSYS itself will be x64, but the toolchain that is going to be installed in the steps below is ARM64 native and natively compiles for ARM64)
• Create a shortcut next to the existing MSYS2 shortcuts. This one should be call C:\msys64\msys2_shell.cmd -clangarm64 (change path accordingly, of course)
• In MSYS2, edit the /etc/pacman.conf file to enable the clangarm64 repository. Look for these lines:

  [clangarm64]
  Include = /etc/pacman.d/mirrorlist.mingw

  uncomment them, and save the file.

• Do the post installation calls to pacman -Syu twice.
• Then finally install the mingw-w64-clang-aarch64-toolchain package (pacman -S mingw-w64-clang-aarch64-toolchain)

At this point, the environment has a toolchain. Other tools can be installed too, like autoconf, automake, etc. The `clangarm64`` repository has several precompiled libraries. (See https://packages.msys2.org/repos)

For configure scripts, the HOST and BUILD triplet is aarch64-w64-mingw32. Clang's default target will already be aarch64-w64-windows-gnu

[simcop2387]

Neat I hadn't seen that toolchain come around finally I'll get my windows 10 arm setup going again and see what I can do. I suspect that there's a few things I have to recompile myself to get started but I'll take a look again.

[hmartinez82]

@simcop2387 I don't know if you can do that In Windows 10. I think that support for x64 emulation is a Windows 11 thing only (you need that to install MSYS itself first)

[pbo-linaro]

For now, clangarm64 variant is experimental, and not all packages are present and they depends on x64 packages. It implies that you still need to have x64 emulation, so its usage is restricted to windows 11 on arm.

The main problem here is that it is not a "gcc frontend" plugged on clang/llvm. This is just symlinks (named gcc/g++) redirecting to clang/clang++, which is what we have tried. Thus, even if some packages might compile easily (like aria2c), others won't be compatible explicitly with clang. It seems to be the case for most of the external libs built for strawberry perl.

[bluespidernav]

Well I tried to install active state perl on a win11 arm64 machine and it failed miserably so I tried strawberry instead and had no issues! I don't see why the Active State x64 version shouldn't just work? Sure an arm64 version might be nice but whatever the issue with the installer is seems higher priority.

[pbo-linaro]

Indeed that's strange, and with x64 emulation it should work directly too. We have been using x64 Strawberry Perl with success too.

[imjosecampos]

Any updates on this?