FOSDEM is what, two days away? I’ve introduced a term for “let’s sleep on it”, “daar moet bier en FOSDEM overheen”, meaning roughly we need to drink beer and go to FOSDEM before making a decision. I’m not sure it will clear heads, but it will certainly be fun.

One of the things I want to do at FOSDEM is show KDE4 running on OpenSolaris. Now, I have packages and everything for KDE 4.0.0 or whatever trunk was last week, but the update to Qt 4.4 throws a serious spanner into the works. It means I need to port Qt 4.4 to Solaris. By friday.

“Port” is a big word here, but “make it compile with the particular collection of tools that the KDE-Solaris team has chosen” is too long to put in a regular sentence. There’s always little issues since using Sun Studio 12 (the current compiler) on OpenSolaris (Nevada, Solaris 11) just doesn’t work out of the box. Qt is tested on Solaris within Trolltech on Solaris 9 and with an older Studio version (I think – the mkspecs file mentions Studio 7 and 8), so it’s not really a surprise that things go south when applying an unexpected toolset. For documentation purposes, here’s issues I ran into (this is just my first run through qt-copy, so it may document issues that boil down to “ade is confused”).

  • configure -help uses bad options to tail. This is because XPG4 tail which accepts the standard -n flag isn’t first in my path; petty issue. This does mean that QMAKE_CONF_COMPILER is not set correctly in configure, and might have bad effects later. Within the usual KDE4 compile environment we do have GNU tail, so this only springs up if you are trying to configure Qt 4.4 in a most-bog-standard environment.

  • qatomic gets both the i386 assembly version and the empty .cpp version, which leads to compile failures much later. I don’t know enough about how qmake handles all those .pri files to understand why it gets in there twice. Editing the make files helps here.

  • the included PCRE uses __inline, which Studio 12 doesn’t like. I’m not sure why pcre is even in there in the first place, it’s a common third-party library.

  • WebKit fails with a compiler assertion, like so:
    >> Assertion: (../lnk/bind.cc, line 268)
    while processing ../JavaScriptCore/kjs/collector.h at line 30.    </br>I know I’ve seen that one before, but I don’t remember exactly what triggers it. Some weird template-fu IIRC. As usual there are probably compiler fixes for this already somewhere in the pipeline, but not in the current compiler folk can actually use.

    The list ends here because I have not yet figured out what’s bugging WebKit. FOSDEM is less than two days away.