Official support for windows-arm64

[Pierrick Bouvier]

On 3/15/24 15:08, Christian Lohmaier wrote:
> Hi Pierrick, *,
> 
> On Fri, Mar 15, 2024 at 11:41 AM Pierrick Bouvier
> <pierrick.bouvier at linaro.org> 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