Created attachment 165960 [details] LibreOffice running on Windows ARM64 in aarch64 QEMU on Linux. Currently the cross compilation at least starts. It even generates an install package, which I didn't yet test. Implementing a working UNO bridge took not as much time as I anticipated - all the cross-build fixes took much more... Not talking about libvirt / QEMU fixes still needed.
FWIW: I propose that TDF runs a tinderbox to keep the Windows ARM64 and also the cross-build in a working shape. Otherwise it's quite likely, that it's basically not utilized and will deteriorate to the state before my patches. A Gerrit build would IMHO be overkill.
Created attachment 166031 [details] My Windows Arm64 build config
All patches should show up in "git log --stat --grep 'Windows Arm64'". While the current LO starts and the build even creates a - still untested - MSI, there is some stuff still missing / disabled, which is available in the other Windows builds and which needs further work (apart from upstreaming the patches and the obvious bugfixes): * .NET / C#: is currently disabled. You could probably build most of it, except for clihelper, which needs a library and header not in .NET 5.0, (mscoree.dll). The header is still in the Git repo at: https://github.com/dotnet/coreclr/blob/master/src/pal/prebuilt/inc/mscoree.h, but not in the SDK download, last time I checked. (That dir is suspiciously called prebuild, so it might not be the real origin of that file / code). * gpgme: uses mingw / gcc to build, which doesn't support Windows Arm64, according to: https://github.com/msys2/MSYS2-packages/issues/1276 * coinmp: probably just needs to add a ARM64 target to the solution file, like I did for lcms2 in commit a8b0503b57a4736df3040e2faa4faf16ef1df062. There is also a newer "1.8" release, just ~two years old. Probably some "interesting" easy hack? * skia: is currently build with MSVC. I had a quick look, but couldn't figure out, if this needs an extra cross-compiler, like for MSVC, or just some switches to select the host CPU when calling MSVC. A quick test already generated errors for the precompiled headers for missing intrinsics, so I'm quite sure I didn't select the correct target. * firebird: configure complains / aborts w.r.t. some tests unable to work for cross-compilation. The source offers a few MSVS solution files for a build, but LO uses configure. I suggest to first check, if the build can use these (and also ask base people), instead of configure. Probably would also get rid of some / all Windows patches and maybe is faster. * StarBasic DLL / FFI support: currently disabled by commit b25aa1cd813478f1cb08bf4f2a79ed83852a33e9. This code needs an implementation for Arm64. AFAIK it's like the "uno2cpp" part of the bridges code, but instead it's just "basic2c", so no state and just C calls. So not sure, if this kind of "code sharing" would work and is desired? Or generally use libffi here, which we already need / use for Python? Since I just did some debugging in QEMU using instdir, I also didn't run any tests. Generally any 32-bit process hogs a CPU core, so there are some more general bugs in either my Windows version or QEMU. The current Windows installer ISOs also doesn't even boot into the installer (QEMU and edk2 git), hogging a CPU with a black screen after pressing a key to start from the CD.
So I've updated the Windows build instructions in the wiki for ARM64. I don't have a fresh install, but my setup just has two entries with ARM64 in the installed components list: * MSVC v142 - VS 2019 C++ ARM64 build tools (v14.2x) * C++ ATL for v142 build tools (ARM64) The LibreOfficeWinArm64.conf is the same then the LibreOfficeWin64.conf, except for the architecture. I tried to build with the new ".NET 5" SDK, which has a native Arm64 build, but it's very different from the previous ".NET Framework 4.x". Currently I think it might be the best to offer the clr interface and climaker, based on the x86 version of .NET 4.x. See https://github.com/dotnet/runtime/issues/36699 for more infos regarding Arm64 .NET. Current state is at: https://gerrit.libreoffice.org/c/core/+/103933 Nevertheless the config without cli support builds here, like described in the Windows build instructions in the Wiki. Use LibreOfficeWinArm64.conf and --with-jdk-home=<Windows Arm64 OpenJDK>, and you get a working instdir and untested MSIs.
After playing around much too long with CliNativeLibrary gbuild, trying to fix the x86 linking of cli_cppuhelper.dll, always looking at CliNativeLibrary_cli_cppuhelper.mk, I finally realized that it actually uses Library_cli_cppuhelper_native.mk, which depends on cppu, cppuhelper and sal. So for this plan to actually work, gbuild would need to build all of these libs for x86 too. I have no idea, how to do this with gbuild in some sensible way, which makes the .NET 5 approach look more promising in comparison, not just as a long term plan.
So the next failure was trying to use the combination of the build / x86 / .NET Framework 4 based climaker with the rest of the Arm64 binaries. Turns out the generated cli_basetypes.dll also has a dependency to mscoree.dll embedded, even if the input is just C# and generated assembly. The whole trip started, because I don't have a mscoree.lib for Arm64, so I'm again at mscoree.lib linker errors. And now I had a look at my test .NET 5 console project and it's dll also references mscoree.dll; and I thought .NET 5 would be different in this regard. And in my Windows Arm64 QEMU, the only mscoree.dll is in SysWOW64. Maybe sometimes the dependency is ignored? I currently don't know what is going on. BTW: we can't build climaker with .NET 5 because we can't save our generated assembly: https://github.com/dotnet/runtime/issues/15704 There is https://github.com/Lokad/ILPack, which even some people working on dotnet/runtime have used for debugging the generated assemblies (see https://github.com/dotnet/runtime/pull/1850). But currently I don't want to go the way of code generation via some external lib, so this build won't have .NET bindings.
*** Bug 141825 has been marked as a duplicate of this bug. ***
CI: https://ci.libreoffice.org/job/lo_daily_tb_win_arm64/ DL: https://dev-builds.libreoffice.org/daily/master/Win-Arm64@tb77-TDF/ I don't have the plan to invest more time in it. It was just a free-time / COVID project to learn about the platform and Arm64 in general and generally fix / implement Windows cross-compilation and the 64-bit selection. No idea, if TDF wants to make it an officially supported platform. I'm not aware of anybody else being interested in it.