windows arm64

Hi, I have extensively searched for an answer to this but cannot find a single reference to it so, LibreOffice for windows arm64. Does it exist, is it on a roadmap? Are there any obvious impediments to me compiling it myself?

Many thanks,

Martin Gregory

edit retag close merge delete

Yes, you are probably the first to try, find the obstacles, and come with necessary patches. You are welcome to join #libreoffice-dev to discuss any specific problems (see https://www.libreoffice.org/community/developers/). Thanks!

( 2020-07-02 11:23:08 +0200 )edit

Sort by » oldest newest most voted

The current answer is simply no. You can try compiling it, but it definitely won't work out of the box. It'll already be a challenge just to get the build setup working:

Problems from the LO code side:

• the configure.ac compiler detection for Windows (probably the easiest to fix)
• the native Windows make (eventually replaceable by Cygwin make, adding ~50%+ compile time)
• running an emulated Intel 32bit Cygwin as a build environment will be problematic
• building / converting the Arm64 Linux UNO bridge for Windows
• building using 32bit environment in general (address space / memory restrictions)

LO does support cross compiling, which IMHO looks like the easier setup to get ready. OTOH AFAIK nobody ever tried / needed to cross-compile on Windows.

Otherwise see Mike Kaganskis comment. It really depends on how much time you want to invest (weeks, I would guess).

P.S. I've just opened tdf#137143 . It's possible now to cross-build LO on Windows x64 for ARM64. The result did start for me in QEMU, FWIW.

more

OTOH AFAIK nobody ever tried / needed to cross-compile on Windows

Note though that we build either 32-bit or 64-bit builds on the same 64-bit host. If VS is able to generate Arm64 images, then it might be reasonably easy (a matter of duplication current 32-bit vs 64-bit set of settings), which can't be said for the other bits like UNO bridge etc...

( 2020-07-03 23:32:03 +0200 )edit

Note though that we build either 32-bit or 64-bit builds on the same 64-bit host.

That is not cross-compiling in the strict sense needed here. You can normally run X86 binaries on a multi-arch X86_64 OS / host. But for the Arm64 build on X86_64, you probably need to build the X86_64 build toolset (gengal, idlc, etc.) and use these to generate all the needed build artifacts (galleries, UNO headers, etc). So "real" cross-compiling is normally a two-step process: build native compiling tools and build the non-native, cross compiled product.

But eventually this is not needed here, as Cygwin is already the emulated 32bit X86 environment. No idea, how this interacts.

Thinking about all this: it's probably better to cross-compile the Arm64 build on X86_64, just for performance reasons (native make + raw computing power), and copy instdir to the Arm64 machine (or run an emulator) for tests / debugging. That looks ...(more)

( 2020-07-04 09:34:49 +0200 )edit

If I took it on I would definitely be looking to cross compile X86 to Arm64. Even for basic web app development VS chugs on my surface pro x, it would be an exercise in frustration to emulate all those tools in 32bit.

Still I have tasted success compiling CodeOSS to arm64 and wondered what something more complex would be like. I don't doubt getting the build environment up is time consuming in itself.

Anyway thanks for the responses, I'll need to dig into the docs before I commit too much time but let's see.

( 2020-07-04 12:33:46 +0200 )edit

So this WE I tried to get something to cross-compile to arm64 on Windows x64. Turned out that LO cross-compiling is somewhat broken in general and was never really supported on Windows (just multi-arch compiling, where you don't need extra build tools). There is now the branch private/jmux/win-arm64, which will compile eventually working build tools to build arm64 on x64. But since Windows never distinguished between build and host, because x64 can simply run x86 binaries, there is still basic stuff broken. Not even talking about all the broken external libraries. And I thought the compiler setup was the easiest problem. It's just one catchall commit, but it's a start.

( 2020-07-06 07:02:56 +0200 )edit