KOffice on OpenSolaris

KWord on OpenSolaris screenshotInge Wallin recently blogged about the portability of KOffice — spurred on, no doubt, by the success of the port to the Nokia n900 and to Haiku. So he listed GNU/Linux, Mac OSX, Windows, FreeBSD (thanks, Inge, for checking), Haiku. That list is missing (Open)Solaris though, which as a UNIX flavor. ought to be a pretty simple target.

Of course, Solaris has been a primary target for OpenOffice for ages, so KOffice is a little late to the game on this particular platform. But I guess that’s my fault, since I’m one of the packagers for KDE4 on Solaris, and I hadn’t gotten around to it yet. So this weekend I spent a little under two hours hammering together a specfile (RPM-style) for koffice and getting the whole darn thing to build. Screenshot of KWord in action as proof. I tried KPresenter as well, but that crashed on changing the list style, so I didn’t think that was a good demonstration.

Of course, no port is without its patches, so here they are:

  • constness — this patch matches the constness of parameters in definitions with those in declarations, so that int foo(const int) is defined with int foo(const int i) and not as int foo(int i). Now, since the last time constness-matching blew up, I’ve learned that this is really a bug in Sun’s compiler, because constness is not supposed to be mangled into the name. However, I’ll claim that code neatness demands that they match, anyway.
  • double — some math functions like sqrt() can take both float or double, and Sun’s compiler doesn’t just pick one when you pass it integer parameters, so we need some explicit disambiguation. This is common all across the KDE codebase.
  • NaN — the KOffice code uses val != NAN which uses the gcc-specific NAN #define; probably !isnan() is better.
  • math — the header file math.h in Solaris uses the identifier “exception”, which becomes ambiguous in the context of the STL, so it needs to be included earlier, rather than later. This patch bungs in math.h as the first include in a number of C++ files — not necessarily something to merge upstream, because it’s mostly working around a bug elsewhere.
  • stupid — yes, this is a stupid patch. I can’t convince Sun Studio that 8.5 * 1440 is an secretly an integer constant and that it shouldn’t complain about a bunch of initializers in the MS Word import filters. I’m not really sure what’s going on here, it’s something special about static const initializers of class variables, since doing the same in a non-class context works just fine.

So there you have it. Five tiny patches for a codebase of a little over 600000 lines of code. Nice. Tip of the hat (I have lots of hats, but all of them are baseball caps and I don’t have a decent Stetson) to Inge and the KOffice folks for a nice portable office suite. You may be troubled, but your code is good.

11 thoughts on “KOffice on OpenSolaris

  1. Shouldn’t one just include cmath instead of math.h for C++ code. This is even necessary to get the correct sqrt for double or float.

    • Using cmath instead of math.h is more style consistent, you’re right. I don’t see how it helps with disambiguation, though — Sun Studio still complains.

    • No reason why they shouldn’t be committed — it’s just I don’t always dare muck about in *every* source tree I look at. Heck, I don’t even think I have koffice trunk checked out right now — most of the time, as a packager, I’m interested only in release tarballs.

  2. Hi and thanks for the praise!

    Did you commit the patches or did you want us to review them first?

    • Only once Krita compiles as well — there’s something missing in the dependency chain, might be an outdated lcms (the packaged one on OpenSolaris is 1.17, Krita wants 1.18, I have an updated package for 1.18 but … no, I hadn’t built Eigen, that’s my mistake. So yeah, there’s a chance, but I need to recompile some stuff first 🙂

  3. Shouldn’t the “double” patch use 4.0 instead of integer division? So it would look like

    double maxRadius = sqrt(width*width/4.0 + height*height/4.0));

  4. Pingback: Kepasaka Blog » KDE everywhere (kde en todo lado)