LibreOffice is now available for Haiku

great work, much appreciated! Is there a blog post on how you did it, what challenges you faced? I remember back in the day an effort was started and with the QT port things got a little easier, right?
Definitely need to install Haiku somewhere natively now…

Presentation on the status in Feb 2018 (FOSDEM)

Wow, really amazing! Great work!

A questions. I remember that there were efforts to port LibreOffice/OpenOffice to Haiku many years ago and the comment was, that its very hard and probably will be easier to make new Office, than port OO, because is complex like entire OS or even more. Is this port a finished effort from those years ago, or is it new one? Does something happen, that it was easier to port this time, than 8 years ago? From the old days Ive got feeling that only Chuck Norris can port LibreOffice, and I havent saw him on this forum.
It`s a lot of ports at one time: Qt, now LibreOffice… While there was near nothing for last years.

Excellent news! Thank’s for your hard work.

I can write a blog post about the effort, although the FOSDEM presentation covers it for the most part.

The first effort was by oco and this effort is completely independent. He started with OOo4Kids, since it was stripped of many dependencies. At this time LibreOffice didn’t exist and I remember from compilation instructions, that OOo even had it’s own build tool (dmake). We didn’t have Java port and OOo depended (heavily?) on that. LibreOffice did a great job of rewriting all of this to GNU make and stripping Java, so that made things easier.

I think the main issue was that LibreOffice requires a lot of libraries. I see people blasting package management for making system unnecessarily complex, hard to tinker with, etc. Let me say this: I wouldn’t start working on this port if package management didn’t exist. I still remember a mess with gcc4 libs being picked up by gcc2 for linking which would throw mysterious errors.
Back to the libraries: porting them was pretty easy but tedious. Most of them compiled out of the box thanks to POSIX compatibility, but some had, for example custom library detection logic and they were PITA to get working (langtag, ixion, orcus).

Now to the VCL backends: currently there are two native backends in progress. First one [1] is completely BeAPI based, for LO 5.3 and that is what was presented at FOSDEM. After my presentation I got feedback that perhaps it would be better and easier if we took cairo backend for rendering and BeAPI for the rest, since VCL is kind of a mess. I started working on that [2], but it didn’t go far - rendering works fine since cairo handles that, but windows don’t even refresh properly on mouse move.

The main problem with implementing BeAPI based backend is Common Text Layout which ensures there are no document rendering differences between different OSes. It also handles right-to-left text, etc. I didn’t manage to figure out how to implement it. but the main issue is that we don’t have APIs for rendering RTL languages. So back to using external libraries like harfbuzz. That makes native backend kind of pointless. (EDIT: harfbuzz is not a bidi library) Now that we have Qt port, cairo is also pointless IMO since it’s almost the same thing. (Using external thing to interface with OS.)

Some answers to this are above, additionally:
I don’t think that’s a worthwhile endeavor anymore.

  1. It looks pretty native now, and even with BeAPI backend you won’t get much better - there is still VCL as a layer of indirection.
  2. (speculation) I’m afraid that LO might even drop native backends in favor of Qt. That would be a lot of work wasted, especially with our strained resources.

I’d love to see native backend, but I think my time can be better spent elsewhere (like WebKit, or fixing bugs in the OS itself). If anyone wants to work on it there is a rough diagram of how things work in BeAPI (5.3) backend [3].

Ending thoughts:
When I started working on the port (2014) there was only an idea on TDF wiki about using Qt for GUI.
IIRC Qt/KDE backend is sponsored by City of Munich which wanted better integration with KDE.
I believe a 1 month full-time contract would be enough to implement a somewhat working native backend, with another month for polishing.

And finally: I’m very glad to see LO finally working! Thanks diversys and 3dEyes for your tremendous work on Qt and KDE. :slight_smile:

[1] GitHub - KapiX/libreoffice_core: Read-only LibreOffice core repo - no pull request
[2] GitHub - KapiX/libreoffice_core at haiku-6.0
[3] LibreOffice for Haiku -


I’m not seeing this happening. Years of effort has been invested in the GTK+3 backend, which is only now getting to a polished state.

For reference:

1 Like

This is pretty impressive news. Congrats to all involved. Now all the questions about when this or that office application will be ported “to make Haiku useful” will not take up space in the forum database.

Will have to check out the FOSDEM video for this. Meanwhile (not to pour water on the parade) - we can port:


  • to Haiku on the Odroid XU4 platform! (kidding).

Great work guys !

  • Ron

Krita is at least already ported :slight_smile:

1 Like

Thanks for the tip!

Now I see blender is there too. Obviously, I’ve been away from Haiku for a while …

1 Like

Don’t forget VLC.

1 Like

TBH, I think a maybe 25-50% longer version of this reply would make an excellent blogpost, especially the bits about how package management made this possible when it wasn’t before, and then the rationale behind using the Qt port rather than pursuing a native backend.


Great work guys! Works just fine on my Thinkpad. Great to be able to use the same office suit I use at work on my main system :slight_smile:

  • Darktable : depends on GTK
  • Gimp : depends on GTK
  • Inkscape : depends on GTK
  • Davinci : ??? which one ??? Resolve is not open source.
  • Krita : port already exist
  • Blender: port already exist
  • Lightworks : not open source
  • Natron : looks possible.

It allways crash then i change the window size.

I downloaded the latest stable GTK source and ran ./configure. Seems like all dependencies except cairo-gobject are met.

Pardon, Dr. Google:
At the start (the selection window), it sticks out of the screen on the left. It does not look as good as it did in the preview, it leaves artifacts on the monitor and generates errors during the attempted application and exit.
The versions boost163, boost164, boost165 and boost166 are available ~ all are activated. The main thing, LO takes the right one …
The tips given here (above) have not all led to the boost165 (missing) being installed. Only the search for it showed that the ‘missing’ boost165 (also) was already in the list, but apparently was not found (Install, pkgman)!?
Manually it worked (apparently). Not usable, but LO 6.2 is still alpha, not even beta … Does that make sense? To try porting a malformed (alpha) application?

It is a bit more complicated than just get the dependencies met.

It is certainly that. Unfortunately, I (and others) keep forgetting that Haiku itself is also alpha (R1 / Alpha 4.1) and that the nightly updates are for everyone, and especially for developers. There are still many dependencies that need to be investigated.
While waiting for Haiku Beta I miss (also) OS / 2 …

Yes, all dependencies are met, and then you get an X11 based GTK. You can then ssh -X to your Haiku system and run apps there, displaying them on a nearby Linux system or whatever. But this isn’t useful for what we’re trying to do here.

Then you can start thinking about running an X server on Haiku and get something like TiltOS did a few years ago. But this is still not what we want.

So, you need to rewrite large parts of GTK to render using the BeAPI rather than X11. And also probably write an “engine” using BControlLook so the apps look nicely integrated. This is a lot of work. Not impossible, but a lot of work.