[Libreoffice-bugs] [Bug 137143] Offer a Windows on ARM64 installer

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=137143

--- Comment #3 from Jan-Marek Glogowski <glogow at fbihome.de> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201002/91d92def/attachment.htm>