Spicy Vinagre

One of the more eventful version bumps during the GNOME 3.2 update was with Vinagre, the Remote Desktop Viewer, which supports a number of protocols via plugins.  These plugins used to be managed by libpeas, a GNOME framework which makes it easier to develop and manage plugins.  However, in the case of Vinagre, it was a bit of an overkill, as the only plugins that were needed were those that shipped with Vinagre itself.

So, during the 3.2 development cycle, the devs decided to replace libpeas with their own VinagreStaticExtension class. In theory, a sensible move, but they made one major mistake: they never added any code to actually load the plugins!

Now that got your attention, didn't it?

Of course, if you try vinagre 3.2 on Linux, you may find that it works perfectly (but we'll get back to that).  But only because they used the most unportable, Linux/ELF-centric hack that I've ever seen (and trust me, I've seen my fair share of them).  It took me a while to figure it out at first, but here is what they did:

1. the plugin init functions are marked __attribute__((constructor)), a GCC extension which causes the indicated function to be called automatically;
2. the plugins rely on symbols in the main binary, of course, but furthermore...
3. the executable also relied on symbols in the vnc plugin, and to top it off...
4. the executable is linked against the plugins!! (If you don't think you misread that, then try again.)

In short, the only reason that this worked is that, by linking the plugins into the executable regardless of symbol dependency, the ELF runtime loader would load the plugin as a runtime dependency, at which time the plugin init function would be called due to being marked as a ctor.

To be fair, technique #1 is also used by LADSPA plugins, and #2 isn't uncommon and can be made to work even on PE platforms. However, #3, while theoretically possible, is impractical with plugins due to a lack of rpath in PE linkage, and relying on #4 wouldn't work at all because with PE only those DLLs whose symbols are required are hard-coded as runtime dependencies. And here's the kicker: even on ELF platforms, this doesn't work if linked with -Wl,--as-needed.

Fortunately, the fix is fairly easy: make the plugins static instead, link them into the executable as before, and actually call the ctors in main(). So not only is vinagre 3.2 working and available with the rest of GNOME 3.2 in Ports, but while I was at it, I added SPICE protocol support as well.

This Lemur can be found outside of Madagascar

(alternative tagline: did you realize that hippos and lemurs used to be neighbours?)

I'm referring, of course, to Avahi. GNOME relies on Avahi to provide mDNS/DNS-SD (aka Zeroconf) functionality. Until now, that's been missing on Cygwin, and for good reason.

In order to deal with anything beyond wide area browsing, Avahi requires low-level networking support, and it currently only has that support for Linux, BSD, and Darwin. Any other platform, and well, you might think you're out of luck, except that we're in good company: OpenSolaris is also a GNOME distro and has been in the same boat. For technical reasons, they chose to make Apple's Bonjour (mDNSResponder) the primary mDNS/DNS-SD service, and patched avahi-daemon to be a client thereof, circumventing the lack of networking support.

It turns out that this solution works for Cygwin as well. A Cygwin-built mDNSResponder wouldn't work for the same reason a vanilla avahi-daemon won't, but the former does work on Windows (as used by iTunes, Safari, and much more). As for the client, since it communicates with the daemon solely via UDP, a Cygwin-native libdns_sd works just fine with a Windows daemon.

So thanks to FOSS, we have a working Windows mDNSResponder, a portable libdns_sd client, and patches for Avahi to use it. The result? A mDNS/DNS-SD stack that works for both Windows and Cygwin seamlessly. The possibilities are endless.

This does mean that you need a working Windows mDNSResponder running on your machine. While it is open source (Apache-2.0), it requires Visual Studio in order to build, so you'll need to get that binary from elsewhere. You might already have it, as it comes with the aforementioned Windows software (look for the "Bonjour Service" in Services or mDNSResponder in taskmgr); otherwise you can download an installer directly from Apple.

Existing GNOME components which can benefit from Avahi have been rebuilt to enable this support, and a handful new programs and plugins have been added as well. A few packages (mpd, xmms2, and libdmapsharing, the latter of which is used by rhythmbox) which support either stack use libdns_sd directly to minimize overhead. As for KDE, 4.6.5 is due to be released upstream any day now, so this feature will be added there as part of that update.

Planting Season

Well, at least in some parts of the world. But not here, it's still below freezing (although not by much).

Yesterday, I was testing the two programs in Ports which use GObject Introspection at runtime (lightsoff and swell-foop), I found that those programs were completely nonfunctional. Not only that, I found that it wasn't just me. But as I dug deeper, I found that everything went wrong at once:

• Pango's typelibs were broken due to improperly shipped GIRs;
• The gtk_clutter_init* functions needed some introspection annotations;
• Seed module loading broke in 2.31;
• The games should have been using GtkClutter.init() instead of init_with_args();
• The games were trying to use a Glib function which was no longer exported;
• The games were not specifying which versions of its dependencies were needed, causing the wrong versions to be loaded if gtk3 libraries are present.

The good news is, four packages and six patches later, the games are working again, and will be shipped in the next upload (hopefully next week).

A Time to Introspect

GObject Introspection looks to be the future of GNOME language bindings, and the good news is, you need not wait until 3.0 to use it. I have just finished adding all the components currently available to Ports SVN, together with Seed, a WebKit-based JavaScript interpreter which automatically includes "bindings" to any of 30+ libraries which ship with Introspection data.

Here is a screenshot of several Seed examples using the GTK+, Clutter, VTE, and WebKit libraries through GObject Introspection. The LightsOff game shown there will be part of GNOME Games 2.28, but I've made a preview of the latest beta release available. All this will be part of the next upload, which I hope will be this week or next.

Google Gadgets for Linux

I just added a screenshot of Xfce 4.6.1 with Google Gadgets for Linux (which I just finished building today) and Konqueror 4.2.4 running on my new computer. Unfortunately, XWin multiwindow mode doesn't have the compositing support to make GGL look right, but it works fine on a desktop.

The Path of Evolution

GNOME Evolution, that is. This is one of those packages that has been bugging me for years; it would build but not run. But in the process of buildings Contacts, Dates, and Tasks, which also use Evolution-Data-Server but have very simple interfaces, I discovered that NSS still wasn't working, causing E-D-S to not initialize. So I rebuilt E-D-S and Evolution without NSS, and voila, it runs like a charm.

So Evolution will be part of the next upload, albeit without SSL support, together with the rest of GNOME 2.26.2. As for SSL support, as much as I would like to have it, I'll admit trying to fix NSPR/NSS again isn't my highest priority right now. (Why can't they use something more normal, like GnuTLS, instead?) As always, PTC.

GtkMozEmbed challenge

One of the biggest things missing from Ports' GNOME is GtkMozEmbed, nowadays often provided by XULRunner. This would allow adding, updating, or new features for the following packages, among others:

Devhelp
Epiphany
Galeon
Kazehakase
Liferea
MonoDevelop
Yelp
Mozilla::DOM
Gtk2::MozEmbed
pygtkmozembed
ruby-gtkmozembed

Besides being extremely large (34MB source), Mozilla has always abused Cygwin as a build platform for MinGW/MSVC. I really don't like it when people do that. Cygwin is a fairly capable platform of its own accord, not just a means to an unrelated end, and treating it otherwise is not just insulting to those of us who use and develop it, but confuses new users to no end. (Which is why I'd be glad to see the end of -mno-cygwin as well.)

But since GNOME starting using GtkMozEmbed a few years ago, I've taken a few attempts at removing all the anti-Cygwin hacks, all ending without a successful build. A recent (partially successful) experiment with Netscape plugins in Konqueror inspired me to try again. Thanks to Gentoo's ebuild, I managed to get a successful build, but it just crashes (although sometimes a window appears for a split second). My gut feeling is that it's a problem in the XPCOM initialization, but at this point it's way beyond me.

So here's the challenge for anyone who chooses to accept it: get XULRunner to run. To get you started, here's my cygport and patch. You'll need GTK+ and the GNOME libs from Ports (with their -devel packages) as prerequisites. The build can be tested with the included TestGtkEmbed.exe, or build and install both Mozilla::DOM and Gtk2::MozEmbed and try the examples. (The latter require a recent patch to cygport.)

If you do succeed, please drop a note to the mailing list with your modified cygport and patch.

Pidgin and SILC

I just finished building Pidgin 2.2.1 with SILC support. But I came across an interesting problem:

SILC can either use GNU MP or its own code for multiple-precision arithmetic, and that causes the problem, because "silcmp.h" begins with:

#ifdef SILC_MP_GMP
#include "mp_gmp.h"
#else
#include "mp_tma.h"
#endif

Only one of those "mp_*.h" headers will be installed, depending on which MP is enabled. But that means that anything building against SILC needs to know if GMP was used or not; if it was, and you don't #define SILC_MP_GMP, then you obviously get errors at compile time (since mp_tma.h is not installed in that case).

For Pidgin, I just worked around this by adding -DSILC_MP_GMP to CPPFLAGS, but there should be a better solution:

1. The best solution would be for SILC to add this flag to silc.pc via an AC_SUBST.


2. Otherwise, Pidgin (and other software depending on SILC) should be calling in configure.ac:
   

   CFLAGS_save="$CFLAGS"
   CFLAGS="$CFLAGS $SILC_CFLAGS"
   AC_CHECK_HEADER(mp_gmp.h, silc_mp_gmp=yes)
   CFLAGS="$CFLAGS_save"
   if test "x$silc_mp_gmp" = "xyes"; then
   AC_DEFINE(SILC_MP_GMP, 1, [Define if SILC uses GNU MP])
   fi

Now you understand why the first solution is much better. But does anyone know how other distros deal with this? Comments Thoughtfully Considered.