Bobulate
Home [ade] cookies
Tribulations of a packager (3)
I’m writing these lines from inside Konqueror 4.3.80 on OpenSolaris. I wrote previously that Konq is much better with WordPress nowadays, so that means I can blog from a browser I like under an OS that I like (or I could boot into FreeBSD and do the same thing thanks to the efforts of miwi and the gang). It was Sinterklaas this weekend, and the ole Sint brought the kids too many toys and brought me updates to the spec files for KDE software on OSOL.
Ben Taylor has picked up the prodigious (or is it Sysiphean?) task of updating the dependency tree for Solaris 10 again.
Elsewhere in the stack, strigi was updated to 0.7.0 (thanks Jos for having an official release available), shared-desktop-ontologies was added at version 0.2 (a simple build), soprano was massaged once, then virtuoso added for version 3.52.7, then soprano massaged again, then cursed, then discarded. Then all the staightforward stuff involved in updating libs, pimlibs, base-* — that is basically updating packing lists to reflect new or changed files and removing the patches that we had pushed upstream.
Virtuoso was .. a trial, in any case. I don’t even understand why the dependency is referred to as Virtuoso when it’s about libiodbc; at that point I end up wondering why we require one ODBC library and not another (e.g. UnixODBC has a Qt SQL driver and is KDE friendly). Maybe there’s more undocumented dependencies underneath there — but I can’t find anything about it. Albert seems to be compiling something completely different when he mentions Virtuoso.
Getting libiodbc to compile at all (the code isn’t all that bad) did show up an interesting pattern: there’s a wchar_t based API and a char based API available, and the interface header does this:
#ifndef SQL_NOUNICODEMAP
#ifdef UNICODE
#define SQLInstallODBC SQLInstallODBCW
This is fine (sortof .. it’s very C-ish) except when the same interface header is included from the library itself. Since the library contains definitions for both SQLInstallODBC(char) and SQLInstallODBCW(wchar_t), the compile breaks. You end up with two definitions for SQLInstallODBCW() instead of one of each. That meant going through and patching each file in the library to not be stupid that way by adding #define SQL_NOUNICODEMAP (I suppose I could have added it to CFLAGS instead). It’s apparent that noone has ever tested this stuff with UNICODE turned on (or perhaps more restrictively, on Solaris with UNICODE on).
Once the library is no longer stupid then it turns out Soprano itself isn’t all that secure about the difference between wchar_t and char. If UNICODE support is on, then consider a line like this one:
SQLExecDirect( hstmt, ( UCHAR* )utf8Request.data(), utf8Request.length() )
Explicitly munging a UTF-8 request into UCHAR (um .. I’m not sure that the non-unicode interface is supposed to understand UTF-8, really) is going to break if that function is #defined to version that expects a wchar_t parameter there. All in all enough to make me give up on this rapidly and think about other parts of the stack instead.
Since there’s still no KDE 4.4 compilation requirements posted on KDE Techbase as of this writing, (and I don’t feel qualified to add it myself based on my rather grumpy interpretation of what needs documenting) it’s hard to figure out what we should be looking for.
Anyway, in positive news all of KDEBase built for 4.3.80, so that’s why I have konq and konsole; PIM needs some additional new patches (remember: if Akonadi, then add_includes(${Boost_INCLUDE_DIRS})) but on the whole it looks like fairly smooth sailing. Expect updated specs for a build maybe next weekend when Ben and Hajma have finished thrashing the repo.