On 3/15/24 15:08, Christian Lohmaier wrote:
Hi Pierrick, *,
On Fri, Mar 15, 2024 at 11:41 AM Pierrick Bouvier
<pierrick.bouvier@xxxxxxxxxx> wrote:
I would like to discuss and offer some help on support for windows-arm64
platform.
That's great to hear!
Linaro, through the Windows on Arm
(https://www.linaro.org/windows-on-arm/) team, has been supporting
various open source projects to enable them on windows-arm64. In
collaboration with Microsoft, we would like to help LibreOffice to offer
stable builds for this platform.
Sounds great!
So far, I've been able to reproduce existing cross compilation build,
thanks to work merged in LibreOffice 7.1. We noticed the existence of
experimental installers, built on a daily basis
(https://ci.libreoffice.org//job/lo_daily_tb_win_arm64/).
We also have installers for all officially released versions e.g.
https://download.documentfoundation.org/libreoffice/stable/24.2.1/win/aarch64/
or
https://download.documentfoundation.org/libreoffice/stable/7.6.5/win/aarch64/
But we don't offer it on our download-pages because we're having bugs
in our bridges code that causes a crash when loading writing aids
using python (or when you try to run python or java macros, i.e. stuff
that uses the bridge code).
We noticed that the lack of available machines for this platform could
be a problem,
Yeah, while cross-compiling is not a problem, actually running it and
debugging the problem is not possible without the real hardware.
If you already built LibreOffice on arm, you can test/trigger the
bridges issue with e.g. a VSCode style launch task that would look
something like this
"program": "C:/cygwin64/home/lohma/build/instdir/program/uno.exe",
"args": ["-s", "com.sun.star.test.bridge.BridgeTest", "--",
"com.sun.star.test.bridge.CppTestObject",
"-env:LO_BUILD_LIB_DIR=file:///$W/LinkTarget/Library",
"-env:URE_MORE_SERVICES=file:///$W/Rdb/uno_services.rdb",
"-env:URE_MORE_TYPES=file:///$W/UnoApiTarget/bridgetest.rdb"
"environment": [
{ "name": "W",
"value": "C:/cygwin64/home/lohma/build/workdir"
}]
That is running the basic bridges test for the c++ bridge in isolation
(defined in testtools/CustomTarget_uno_test.mk - "make check" would
also run this one)
The code for the c++ uno bridge is in bridges/source/cpp_uno and
there's a basic description of UNO and description of the interface
proxies at https://wiki.documentfoundation.org/Documentation/DevGuide/Advanced_UNO
- albeit a bit dated)
The bridges code uses assembler to for passing stuff around between
the runtimes and do type matching, and somewhere in there is a bug -
might be an alignment issue but I so far just lacked the skills to
look at it/the time to require the necessary skills...
and we discussed that with Microsoft, which could sponsors
up to two (physical) machines for this.
Let us know how we can help!
Thanks for the offer, now the hard part begins: Finding people with
the required skills to make use of that ;-)
Thanks for your encouraging answer!
With the answer from Thorsten, it seems like we could have a nice
solution to support this platform.
I'll loop this with our contact at Microsoft, and see how it could be
possible to send machines.
Regards,
Pierrick
ciao
Christian
