Bobulate


Archive for the ‘OpenSolaris’ Category

Newer OSOL packages

Monday, January 10th, 2011

KDE 4.5.4 (why wasn’t that codenamed "pound" or such?) was released some time ago, so there’s updated OpenIndiana packages available. You can find them at the KDE 4.5 package repository. The naming is now deceptive: it’s KDE 4.5.4 in the 4.5.3 repo. Use specific FMRIs if you want to stick to the previous version. Only KDE packages were updated, so all the dependencies stay the same.

We have decided to drop OpenSolaris build 134 as a target. You can use these packages on OpenIndiana build 147 or later or Oracle Solaris Express build 151a. Maintaining compatibility with the older OSOL was increasing the complexity of building packages, putting our resources under strain. So we dropped it. We’re also still on the fence regarding Solaris 10 — no one seems to want it, which means that it may be swept under the rug sometime as well.

KDE 4.6.0-beta1 packages available for OpenSolaris, OpenIndiana

Thursday, November 25th, 2010

The first beta of KDE 4.6.0 has rolled around, pretty much on schedule. In the KDE4-OpenSolaris community we’ve been following closely, building trunk as much as possible and upstreaming those patches that make sense. So we’re happy to announce that for the first time there are 0-day packages available for OpenSolaris-type systems using Sun Studio (I’ve got to add that last proviso because the Belenix guys do a good job of producing packages with gcc).

The packages can be had from the 4.6.0 package repository and include Plasma Desktop Workspace, KDE sdk, Konversation and Amarok along with a bunch of other things. There’s no KDE PIM, edu or KOffice because of various compilation problems that we have not yet been able to solve or functionality issues (e.g. KMail crashes in all of its GPG handling in a way that makes me suspect a compiler bug, but I haven’t been able to track it down well enough yet). The specfiles repository from which these packages are built is available too.

Supported Platforms: the packages are currently available for x86 only. In a poll we did some time ago there was little enthusiasm for specific 64-bit packages, so we have not been building them. Anyway, the Solaris kernel can mix-and-match 32- and 64-bit applications and libraries, so there’s not much lost. There’s no SPARC packages, in spite of some recent success in getting things to build. Here’s the list of supported platforms:

  • OpenSolaris build 134, x86 Edit: while the repo should build on 134, these packages will not install there because dependency names have changed.
  • OpenIndiana build 147, x86

Just those two, hunh. Later builds of either should work, but have not been tested. Oracle Solaris Express 2010.11 should work (it names itself build 151) but has not been tested. Solaris 10 is not supported, as it uses a different packaging system and needs lots of other updated software.

How to get it: set your kdeips-dev publisher to the new repository URL, refresh and install. Something like this should do:

pfexec pkg set-publisher -O http://solaris.bionicmutton.org/pkg/4.6.0/ kdeips-dev
pfexec pkg refresh
pfexec pkg install KDEbase-apps

PS. I’d like to welcome Onno Molenkamp to the fold. He’s been doing 64-bit builds for us and tackling some long-standing annoyances (in Virtuoso and Qt) that make the build less pleasant than it might. The #kde4-solaris channel now has random bits of Dutch on it, too.

PPS. KDE4-OpenSolaris acts as an "upstream" for OpenIndiana. We’re "downstream" from the work done by the KDE community, and massage the code a little and send it off again. There is plenty of scope for cooperation, and we’ve seen recent conversations about having various parties interested in stuff to work together more effectively. (Here "stuff" is Qt and KDE frameworks as well as KDE applications and Plasma workspaces).

PPPS. Solaris 10 isn’t dead as far as we are concerned, just very much unsupported and uninteresting as a target (even if it has a decent installed base of corporate use). Some people try building our specs every now and then and we do try to avoid actively breaking stuff for S10.

PPPPS. We know not all of our patches are acceptable for upstreaming. Some actively break stuff for other systems. Those are the kind that don’t go anywhere else. Sometimes we massage things until they are acceptable. It’s a bit of a trade-off. A shout-out to the author of Sentinella, Carlos Olmedo Escobar, for contacting me about the Solaris packaging we’ve tried to do and the patches that required. I hope to have Sentinella running on OpenSolaris pretty soon.

Futile? Yes, but not pointless (Qt 4.7.1 on SPARC)

Monday, November 22nd, 2010

I feel so conflicted. Just look at that screenshot.

Qt 4.7.1 demo browser running in GNOME, on Oracle Solaris, on SPARCv9

Qt 4.7.1 demo browser running in GNOME, on Oracle Solaris, on SPARCv9


I was considering starting this blog post in a mad-scientist fashion, “mad, was I? they said I was mad to try! haha! and now I shall unleash my creation upon the world and show them all! hahaha!” but I’ve probably done that before. So what you see there in the screenie is probably the first WebKit browser running on Solaris on SPARCv9 hardware. It is the demo browser from Qt 4.7.1. Compiling Qt took just under six hours, I think, but I went shopping in the meantime.
So this is ultimately futile: SPARC hardware just doesn’t get used for the desktop, does it. However, the KDE4-OpenSolaris has had requests from various folks about Qt on SPARC, built with our optimizations and with the Sun Studio compiler. So now it’s here. That is to say, it compiles and some bits run. We still need to figure out how to merge packages so that the IPS repository will spit out a suitable Qt package (either x86 or SPARC). The pkg(5) and pkg.depotd(5) programs know how to handle multiple architectures, I just don’t know how to move the files around to achieve that.
But this exercise isn’t pointless. It shows up how portable Qt is (within the X11 world, anyway). It shows that the packaging setup that the KDE4-OpenSolaris group has set up actually targets the things we said we wanted to hit (which, even after revising away Solaris 10, still includes SPARC). It might help a teensy bit with code quality to consider the warnings a different compiler throws out — although stuff like "textedit.cpp", line 154: Warning: tb hides TextEdit::tb. isn’t useful in my book.
Another thing this experiment shows is that there is more work to be done in catching CStd-based firefox plugins. The Qt demo browser cheerfully tries to load the flash plugin and then falls over because of bad library initialization (when mixing different STLs, see this post of mine for some details) if there’s any interesting media on the page. In the screenshot, we see www.kde.org, which doesn’t do anything fancy.
So there you go. One more platform Konquered (er .. it’ll take another week to get through to KDEbase).

An exercise in futility (nv151 on Ultra 45 with XVR-2500)

Sunday, November 21st, 2010

Oracle has released Solaris Express 11. That’s a binary-only preview of Solaris 11, which picks up somewhere after OpenSolaris was killed. The kernel identifies itself as snv_151a. As an exercise in futility, I decided to install this on my Sun Ultra 45 workstation — a SPARC machine. Of course I’ll be doing so only to evaluate the software I am creating (or packaging) for the Operating System, not putting the machine into production use — which is what the onerous license agreement (it’s even difficult to find the URL to link to!) demands.

I have a SPARC-based workstation under my desk, from the time that we in the KDE4-Solaris project actively targeted SPARC; that’s some time ago. The machine is still there and I like the architecture, so I try to use it every now and then. With OSOL this was always problematic. Solaris 11 seems to change that a little.

Solaris 11 comes with a text-based installer for SPARC, which is good enough. It doesn’t seem to come with a graphics driver for the XVR-2500 card that’s in the workstation, though, as the boot process tells me that the pciegfx domain will not be used.

For me it was a little confusing that some GNOME packages were installed — like gnome-audio — but no X server or display manager. Text logins are fine, but in order to test my software at some point I’m going to have to actually run X on it. Given the speed at which this machine compiles (random hardware begging: anyone have 2x1GB DDR PC2700 ECC DIMMs left over? Or four of them, for that matter? How about an UltraSPARC IIIi CPU @1.6GHz?) I’ll be happy to get through to Qt sometime in the next seven days. And let’s face it, Qt 4.7 keeps trying to outsmart the KDE4-OpenSolaris team by saying that it’s partly incompatible with Sun compilers — but in the case of Sun Studio 12 on SPARC it might be right :)

Turning the SPARC machine into a usable GNOME box took steps like these:

pkg install xorg evince gnome-terminal gdm
pkg install xorg-video kfb xorg-kfb fbconfig-kfb
pkg uninstall xorg-video xorg-video-wsfb

That last uninstall was to get rid of the wsfb driver which crashes Xorg. After mucking about a bit I got some advice on IRC, from the indomitable Alan Coopersmith in particular. You can find some of his work (newer Xorg) on the OpenSolaris forums. So two essential things: "fbconfig -dev kfb0 -defaults" and "pkg install slim_install", then reboot. So thanks, Alan.

The machine will come back but still be in text mode. SSH is enabled by default, so you can SSH in from another machine on the network and start the gdm service to get a login prompt. with “svcadm enable svc:/application/graphical-login/gdm:default“. If you watch the console, after about 15 seconds you get a gdm login screen. On the one hand, it’s tastefully done with some transparency applied around the session and language selectors; on the other hand there’s this giant Oracle logo on there like “abandon all hope ye who enter here.” And a kind of icky hex grid background and default wallpaper, as if drone-like creatures are going to lay their proprietary eggs in your brain and cause you to surrender your will. Ugh.

Why does the Oracle logo look so out of place on a GNOME desktop where the OpenSolaris one didn’t? Seems strange to me.

Anyway, it seems that Oracle have delivered a technically sufficient OS release for SPARC workstations. I can start compiling stuff on it now (some setup scripts will surely be added to the -460 repo as I carry on with that). Making a SPARC machine a usable development workstation takes another whole bunch of packages, just some of which are the Mercurial and the C++ compiler (you could choose gcc instead, but that’s not the mandate of the KDE4-OpenSolaris project). The Sun compiler is not available from the Solaris 11 package repository right now, so get it from the older OSOL repo:

pkg install mercurial
pkg set-publisher --non-sticky \
  -g http://pkg.opensolaris.org/release/ opensolaris.org
pkg install sunstudio12u1

How new software ends up on KDE4-Solaris

Wednesday, November 17th, 2010

I really like it when new software packages are mentioned in blogs or on the dot. Those — based on a combination of personal interest and seeing how the community reacts — drive my selection of packages for OpenIndiana and OpenSolaris (such as it was). Something like the dot story on Sentinella says to me “this is interesting software.”

So I’ve started to package Sentinella, and you can find progress in the -460 repo. What progress? You ask. Yeah, it’s not trivial and the code shows some gcc-isms, for which I have filed bug reports. So as of this writing, there’s no Sentinella spec file in there. It’ll come.

I spotted a new poppler release (1.5.2) in its work towards a 0.16 version. I think I spotted that in a Freshmeat RSS feed somewhere. Packaged most of that up, although it too has some gcc-isms. Balked at registering for the FreeDesktop bugzilla, here are the patches. A gcc-ism for variable-length arrays, introducing a Solarisism for RPATH, using the <ios> header to get std::hex and std::dec, and a gcc-ism around unicode strings. Simple.

Speaking of unicode strings, it seems that gcc will take “\u0161″ as a unicode string and encode it in UTF-8 as two bytes. The Sun compiler doesn’t like that as it interprets \u0161 as a UTF-16 character, which doesn’t fit in a char. On the other hand, U”\u0161″, a unicode character string, is not a char * but a short *. I ended up using gcc to determine that “\u0161″ is the same as “\305\241″ (octal!) and patched poppler to use that.

But while searching for some information on unicode strings, I found Lukas Lalinsky (see, no unicode for me; sorry Lukáš) blogging about taglib releases, so I bumped that one as well.

I guess the summary answer to “how does software end up in the KDE4-Solaris specfile repository and package server?” is “it’s a crap-shoot depending on what I notice.” That’s not entirely good, but it also means that we’re largely driven by KDE needs.

In closing, a shout-out to Jarosław and the KOffice folk for providing some really useful information for packagers. That deserves a whole separate post (e.g. when KOffice is indeed packaged for OpenSolaris and OpenIndiana).

Some notes on OpenSolaris packaging

Wednesday, November 10th, 2010

Thanks to the fine folks at Belenix and OpenIndiana, the package serving mechanism for the KDE4 OpenSolaris packages has changed. Changed for the better, because we now use Apache HTTPD to serve up the files themselves. This removes one of the big issues with our earlier package-serving setups, which was that connections and downloads were unreliable and it could take many many attempts to get a large file.

The trick is to use Apache with a reverse proxy (ProxyPass directive) to pass on some requests to an internal pkg.depotd and to use a rewrite rule to modify other requests to match the on-disk layout of the repository. Sriram N, Shawn W and Alastair helped out in finally pushing this out the door.

As a side effect, the correct publisher to use for KDE 4.5.3 packages — including the Plasma Desktop, KDE Platform and KDE applications — has changed. We will no longer be futzing with port numbers in public, but instead have a human-readable URL. To set up your system to use the latest KDE packages, use

pkg set-publisher -O http://solaris.bionicmutton.org/pkg/4.5.3/ kdeips-dev

That particular URL will only serve 4.5.3 packages and such updates and additional applications as slip in. Eventually, we will get a /4.5.4/ package repository as well. We’re still debating a little on how to do a “4.5″ or “latest everything” repository. Some measure of deduplication would be nice if we’re going to be serving up multiple repositories.

SysV packaging: On a vaguely related note, I’ve regularly had to battle SysV packaging on OpenSolaris. The legacy packaging system (pkgadd, pkginfo) and the new package system (IPS, with pkg as the main tool) are usually well-integrated, but there are edge cases that break stuff — usually the legacy bits. However, the build system (pkgbuild, which is pretty much rpmbuild for Solaris as I understand it) uses the legacy package system for information even while it builds modern packages. So that means I sometimes have to fool pkginfo(1) into thinking that a particular package is installed (or not).

To fool pkginfo(1), you need to manipulate the directories in /var/sadm/pkg. There is a directory there for every package on the system that is known to the legacy packaging system. To hide a package, just thrown away the directory (probably tar it up). Each directory holds a pkginfo file, which is a straightforward key=value file; to tell pkginfo that a package exists, just create a directory of the appropriate name and copy an existing pkginfo file in there, then adjust the contents so it vaguely makes sense. The important settings seem to be PKG and PKGINST. The rest is important only if you’re dealing with officially supported software.

Future of Solaris10 packaging: The specfile repository that we maintain has a lot of material that is there specifically to support Solaris 10. The people who are active in the repository don’t use S10, and I think the complexity imposed by supporting OSOL and S10 is starting to hurt. If we’ve got a complexity budget, it would be much better spent in supporting OSOL and OI (e.g. the future) instead of the past. No concrete plans yet, but I can imagine us tagging the repo at some point with eol-s10 and then ditching all the Solaris 10 support. Thanks to repository history, it’s not really gone, but won’t burden us in the future.

Long-standing Konsole bug in OSOL squashed

Wednesday, November 10th, 2010

Consider the following snippet of C code:

write(1, "foo", 3);
write(1, "bar", 3);
write(1, "", 0); write(1, "", 0);
write(1, "moose", 4);

You expect to get 10 bytes on stdout like this (“foobarmoos”). The 0-byte writes are no-ops. In OpenSolaris, though, we’ve had a long-standing bug in Konsole that makes it hang sometimes. Well, not hang per se, it just ignores all subsequent output from the shell. It took some time before we discovered that it wasn’t hanging, just ignoring output and that you could still interact with the shell (e.g. type “exit”) to recover somewhat.

Various attempts at a fix have been tried. There are two hacks in kdelibs kpty library right now that attempt to address the problem. One accounts for FIONREAD returning 0 bytes available to be read and the other pushes two streams modules on to the terminal. The former doesn’t catch all the cases that block further output, and the latter breaks terminal size setting, which is terribly annoying. Most things assume 80×24 when TIOCGWINSZ fails.

But the basic assumption is that when FIONREAD indicates that there is data available from the terminal, that read() will always return more than 0 bytes and that 0 bytes indicates an end-of-file situation. Testing (and it’s annoying testing, driven from an xterm-only failsafe login with twm) indicates that 0-byte writes drop 0-byte chunks into the stream that kpty sees — a typical sequence is this: FIONREAD returns 10; read() returns 6 bytes (“foobar”); read() returns 0; read() returns 0; read() returns 4. Those two 0-byte reads correspond to the 0-byte writes in the stream, and they tell kpty to close the stream, which in turn stops output from reaching konsole.

I suppose the Linux and FreeBSD terminal subsystems suppress these 0-byte writes; I really don’t know why Solaris does amalgamate non-zero writes (e.g. “foo” followed by “bar” arrives as “foobar”) but keeps 0-byte writes on their own. Maybe it’s a matter of “don’t do 0-byte writes”, but experience shows that 0-byte writes happen all the time, in error messages, when hitting ^C in the shell, and other situations. So on Solaris at least, kpty needs to be armoured against them.

I’m building an updated kdelibs package now, it will hit the package server repo on bionicmutton later today, and I pushed the changes — also with some other Solaris corner cases — into KDE SVN for KDE 4.6 later. It feels good to sit down and finally ferret out a fix.

Sun Ray restored

Friday, October 29th, 2010

It’s been ages since I wrote (or complained) about Sun Ray Server Software (SRSS) on OpenSolaris in combination with KDE4. That was because I wasn’t using it and my Sun Ray terminal sat idle. But a bit of house-rearranging has made the device useful again, and I spent an hour futzing with it today to get things working again.

SRSS is a bit complicated — it’s officially delivered only for Solaris 10 and it exists separately from the client devices, so just because you have a Sun Ray doesn’t mean you can do anything with it. Certainly there’s issues on OpenSolaris (or OpenIndiana). I seem to have 4.2 running — it’s a bit unclear whether there’s a version 5 available, and last time I blogged about SRSS it was enthusing about the new addition of Porter-Duff compositing, which made the Plasma Desktop beautiful on the thin client again.

A good official(-ish?) source of information on SRSS is the sun-rays.org wiki which has a section on getting this stuff to work on OSOL as well. Plus notes for build 134 or later, which is what KDE4 requires. Two blog entries I found very helpful were Chris Gerhard about build 130 and later and the Grey Blog on 2009.06. Both point out some tweaking that’s needed to get gdm to like the thin client — otherwise it starts on the thin client and stops about 60 milliseconds later.

After adding the requires symlinks and font paths, gdm starts up normally.

From there, I can now display KDE4 on my FullHD TV downstairs while the server hums gently in the attic. It’s nice to be able to move around in the house and have the desktop available everywhere. Session resume is also supported, so if I switch off the Sun Ray and switch on again later, my desktop is there.

Another benefit of having a desktop available in the living room is that it enables pair programming when random developers stop over, but that’s a topic for another time.

KDEPIM 4.4.7 available in OpenSolaris

Monday, October 25th, 2010

Since Allen pointed out that the KDE PIM team had released another 4.4 version, we’ve bumped the KDEPIM version available for OpenSolaris through our KDE 4.5 series specfile repository. PIM hasn’t done a 4.5 release as such, concentrating on 4.6 and a full Akonadi-based release, so it’s good to see updates and bugfixes going on nonetheless.

You can build the software using the specfiles — we have not uploaded newer packages. That will have to wait until we’ve done a little more research into how to best serve up packages (as more people are using them now, we’re hitting various performance issues in the way we do things).

A little bit Elfish

Friday, October 22nd, 2010

Q: how many different STL implementations are there available on OpenSolaris?
A: at least five by my count: Cstd, stlport4, stlport5, stdcxx4 (either as package from Oracle or from our KDE4-Solaris packages) and g++.
Q: can you mix and match them?
A: only if you like interesting segfaults. Take ‘Hello World’ and compile as follows: CC -lstdcxx4 hello.cc. Ignore the (dire and in this case serious) linker warnings. See program. Run program. Run, program, run! See program dump core right on the new carpet. Bad program. The crash happens inside the static constructors of one of the two libraries as it calls methods in the other one which has a very different idea of how things work. LD_DEBUG=libs might help you spot this. Compare also CC -library=no%Cstd -lstdcxx4 -lCstd versus CC -library=no%Cstd -lCstd -lstdcxx4 (the former crashes, the latter doesn’t, for some reason).
Q: so why is this a problem?
A: plugins make this a problem. If you load a plugin (i.e. dlopen() a shared object) which uses a different C++ STL library from the one you’re already linked to, then you hit the problem described above:
Q: so how can that happen?
A: different parts of an OpenSolaris system are built with different C++ STLs. This is a historical problem; at some point there were plans to slowly migrate all the desktop-relevant stuff to stdcxx4 (that’s the Apache STL, by the way).but it’s a big effort and takes time. One component that is still built against Cstd is Firefox. So all the Firefox plugins that are written in C++ or that use system components in C++, link to Cstd. Like, for instance, libtotem plugins.
Q: so just don’t load them, right?
A: how do you identify “them” then? In Qt 4.7.0 the demo browser (WebKit based) goes and loads all the Firefox plugins, pretty much on startup. And that crashes in a slow and strange way — it dlopen()s a libtotem plugin, loads in libCstd, runs the initializers on libCstd and boom. It’s probably related to the order in which the libraries are loaded. In any case, we don’t know beforehand what libraries a given plugin uses nor can we say what plugins there are.

If you like, you can pretend this was a conversation between Legolas and Haldir and not a run-in to looking at library files in ELF format.

So, having established that plugin loading can kill a Qt application in a gory fashion and that it happens in practice, the KDE4-Solaris team (a kind of Fellowship of the Ring, committed to binding themselves in the darkness that is OSOL) went looking for a solution. With /usr/bin/dump -Lv you can get a listing of dynamic items in an ELF object, including the libraries it’s going to load (e.g. grep for NEEDED). We decided that a likely place to insert a check was in QLibrary::load_sys(), which has some code to search for libraries and also already has some checks in place for strange platforms. So we had in mind something like bool is_library_acceptable(const char *filename) which would do the necessary check. If the library that’s about to be loaded uses Cstd, then don’t load it at all and return failure. That way, we avoid the mysterious crashes caused by STL incompatibility.

When mucking about with ELF files, the obvious resource to use is libelf. However, the libelf available on OpenSolaris is incompatible with largefile support. Why? Because it uses off_t in some structures instead of a 64-bit offset which could accomodate but 32- (non-largefile) and 64-bit (largefile) offsets. It does have the decency to #error out.

I suppose gelf would have been a solution. But thinking about the problem of finding which libraries are NEEDED by a loadable object, I came up with the following algorithm (which applies regardless of which ELF reading approach I’m using):

  • Read the ELF header
  • Find the ELF .dynamic section.
  • Scan the .dynamic section for NEEDED tags, look them up in the .dynstr section.
  • Bail out if libCstd.so is mentioned.

The precise details — sizes of headers, layouts of structures — depends on whether it’s a 32-bit or a 64-bit ELF file, but the alogrithm remains the same.

I initially coded this in C, with macros. (Bear with me here — I realize now that I tend to iterate over my own code as I understand the problem and solution space better, so I often start with something horrible that gets improved later). Then the code ended up looking like this:

#define ALGORITHM_STEP(d0,d1) \
  /* a step using values from d0 and d1 */
if (is32) { 32bit_t d0,d1; ALGORITHM_STEP(d0,d1); }
else { 64bit_t d0,d1; ALGORITHM_STEP(d0,d1); }

Ugh. From there I went to C++ and template functions. Each macro became a template, but I could also put the types in there, albeit a little awkwardly:

template <typename t0, typename t1> ALGORITHM_STEP()
{ t0 d0; t1 d1; /* a step using values from d0 and d1 */ }
if (is32) { ALGORITHM_STEP<32bit_t0,32bit_t1>() }
else { ALGORITHM_STEP<64bit_t0, 64bit_t1>() }

Feel free to go “Ugh” again, especially if you’re an experienced C++ template hacker. Oddly enough, I haven’t written much in the way of neat template code, just usually debugged what others have done. So by now my program was a bunch of template functions and then a main function with a sequence of if (is32) {} statements to string together those template functions. I could actually collapse it down to just one if() statement, but then the template would have 8 or 9 parameters and it’d be even more ugly than it already is.

From here I remembered non-type template parameters and specializations. It came down to this: define a template class with an integer parameter that can be specialized to hold the 32- or 64-bit types that I need. This looked like so:

template <int> class elftype;
template<> elftype<32> {
  typedef 32bit_t0 t0; typedef 32bit_t1 t1; } ;
template<> elftype<64> {
  typedef 64bit_t0 t0; typedef 64bit_t1 t1; } ;

Not much change in the program itself, except that instead of writing 32bit_t0 I’d write elftype<32>::t0. But this specialization approach applies to the functions themselves, too, and they became:

template<int n> ALGORITHM_STEP() {
  elftype<n>::t0 d0; elftype<n>::t1 d1;
  /* actual algorithm step */ } ;

Now it makes sense to collapse the whole thing into a single function parameterized by 32- or 64-bits, and then the main function I was looking for becomes something like this:

/* read ELF header */
if (is32) { return is_library_acceptable<32>(); }
else { return is_library_acceptable<64>(); }

The algorithm needs to be written only once, it’s specialized for the two cases, the types are neatly squirreled away in their respective class templates. Although functionally it’s no different from the original C version, I find it much more satisfying — for one thing, it’s extensible in a way that wouldn’t be easy with macros (say if there’s a 48-bit ELF format).

And the original purpose, of checking whether a plugin is usable before loading it? We’ve got that patched in for the next package release of Qt 4.7.0 on OpenSolaris, and the demo browser won’t crash anymore (but it won’t play whatever libtotem supports, either).