Tribulations of a packager (3)

Posted on

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:

#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.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.

5 Comment(s)

  1. libiodbc is the compile-time dependency for the Soprano Virtuoso backend. At runtime, in addition to libiodbc, virtuoso-opensource itself is also needed. libiodbc is just the interface used to talk to virtuoso-opensource.

    1. Kevin: thanks for (both) explanations. OK, I can remove the -DUNICODE and hope it (= soprano in this case) compiles then. As far as software selection goes I’m still left wondering why this particular ODBC implementation is demanded. After that all that’s left is kind of sad snarkiness for a basic KDE desktop now requiring two different database servers for basic operation.

  2. As for the support for UNICODE, it’s probably a Window$-only feature. Of course the non-UNICODE interface supports UTF-8 (at least if you’re using a UTF-8 locale), “UNICODE” really means UTF-16 here. (They check the UNICODE macro because that’s how M$ calls it.) I guess they didn’t anticipate that another OS would use that broken UNICODE macro as well (instead of just making their 8-bit charset UTF-8).

  3. I’m not 100% sure either why libiodbc is needed as opposed to unixODBC or some other implementation, but AFAIK it’s because that’s apparently the only implementation Virtuoso supports (and they only support that one because it’s their own).

    As for the “two different database servers” part: MySQL is a relational database using SQL for queries, Virtuoso is a “semantic” (RDF-based) database and primarily uses SPARQL for queries. They aren’t interchangeable. (Though there are plans to make Akonadi use Nepomuk/Virtuoso to store its data, it doesn’t necessarily need a standard relational database, but right now that’s what it’s written for.)

  4. Can you please post the issues to the kde-buildsystem list ?
    “if Akonadi, then add_includes(${Boost_INCLUDE_DIRS}))”
    sounds like there is something wrong, and a blog is not the best place to discuss this.


Comments are closed.