Re: Official support for windows-arm64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ;-)

ciao
Christian




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux