Going to Akademy



I’m going to Akademy! Akademy 2016, as part of QtCon, that is. I missed last year in A Coruña because it conflicted with my family summer vacation, but this year is just fine (although if I was a university student I’d be annoyed that Akademy was smack-dab in the middle of the first week of classes — you can’t please everyone).

Two purely social things I will be doing are baking cookies and telling stories about dinosaurs. I have a nice long train ride to Berlin to think of those stories. But, as those of you who have been following my BSD posts know, the dinosaurs are not so backwards anymore. Qt 5.6 is doing an exp-run on FreeBSD, so it will be in the tree Real Soon Now ™, and the Frameworks are lined up, etc. etc. For folks following the plasma5 branch in area51 this is all old hat; that tends to follow the release of new KDE software — be it Frameworks, or Plasma, or Applications, or KDevelop — by a few days. The exciting thing is having this all in the official ports tree, which means that it becomes more accessible to downstreams as well.

Er .. yeah, dinosaurs. Technically, I’m looking forward to talking about Qt on BSD and KDE Plasma desktop and other technologies on BSD, and about the long-term effects of this year’s Randa meeting. I have it on good authority that KDE Emerge^WRunda^W KDE Cauldron is being investigated for the BSDs as well.

Time flies for FBSD updates, too

So it’s been some time since I last wrote something about the KDE-FreeBSD ports. Time flies when you’re having fun (in my case, that means biccling around Zeeland and camping). In the meantime, Ralf has been hammering on the various Qt ports updates that need to be done — official ports are still Qt 5.5.1, but we have 5.6 done and 5.7 on the way. Tobias has been watching over the plasma5 branch of the unofficial ports, so that it’s up-to-date with KDE Frameworks, Plasma and Applications.

The older KDE stuff — that is, KDE4, which is still the current official release for the desktop on FreeBSD — is also maintained, although (obviously) not much changes there. We did run into a neat C++-exceptions bug recently, which was kind of hard to trigger: running k3b (or ksoundconverter and some other similar ones) with a CD that is unknown to MusicBrainz would crash k3b. There’s not that many commercially-available CDs unknown to that database, so I initially brushed off the bug report as Works For Me.

Good thing Methyl Ethel is still relatively obscure (but a nice band to listen to). They trigger the crash, too.

At issue is the visibility of C++ exception symbols; when -fvisibility=hidden is used and C++ exceptions are thrown out of a shared object, then users of that shared object may not catch the exceptions. Making exception classes explicitly visible fixes the problem — which in our case was because libkcddb catches exceptions from MusicBrainz, except when -fvisibility=hidden is used in linking and executable that uses libkcddb and libmusicbrainz5, in which case the exception isn’t caught and ends up crashing the application.

https://gcc.gnu.org/wiki/Visibility has been very useful in sorting this bug out. After Tobias identified the exceptions as the root cause, I played with code across the shared-object-dependency chain until I came up with a patch which I’ve proposed upstream (e.g. libmusicbrainz5) and in the packaging for FreeBSD.

Even older software sometimes shows interesting bugs. And time flies when you’re having fun, but also when tracking down unhandled exceptions.