A Qt hat, isn't it?

Fedora users may have noticed that F16 ships with Qt 4.8-RC. While I'm not sure what the rush was, it did cause an interesting problem when it came to the cygwin-qt cross-compiling package.

Building anything based on Qt requires more than just headers and libraries; Qt's object system requires code to be processed by moc, which generates additional C++ code for signal/slot handling and the like. There is also a number of other tools which "compile" various types of data into C++ code. I had been relying on the native tools in qt-devel to do this, since the generated code is not arch-specific.

The problem here is that moc-generated code is very internal-specific; code generated with one version of Qt will not compile with headers from another version. Since the version of cygwin-qt needs to match that of the Cygwin (Ports) qt4 package, and I have no plans of updating that to 4.8 until its proven stable in conjunction with KDE, this created a bit of an impasse. There was another issue with relying on qt-devel, in that qmake requires patches to build libraries or plugins correctly on Cygwin, which limited cygwin-qt cross-compiling to CMake-based packages.

The solution to all this was to change the cygwin-qt-qmake package, which had previously just included qmake mkspecs, to provide native-built tools from the same version of Qt as cygwin-qt and with the necessary patches. While qmake/moc/rcc/uic are always statically linked with the necessary Qt code, the linguist, qdbus, and qt3support build tools are linked against the Qt libraries; for now, they are also statically linked with their Qt prerequisites.

The updated cygwin-qt and cygwin-qt-qmake are now available for Fedora 14 and up on both arches, along with an updated cygwin-filesystem to support these changes. Even better, thanks to a patched qmake, I was also able to add cygwin-qscintilla and cygwin-qwt packages.

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.

Fedora Cygwin repos moved

I have updated the Fedora 14 Cygwin gcc to 4.5.3, and have added the toolchain packages built for F15 as well.

In order to properly support multiple RPM repositories, I had to relocate the Fedora Cygwin repos to Cygwin Ports' FTP area. You will need to manually update the release RPM (with 'rpm -U') followed by yum update in order to get the new packages.

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.

Fedora Cygwin RPM repository

I have uploaded the first stages of the Fedora Cygwin RPM repository for Fedora 14 i686 and x86_64. I have added a release RPM which will allow installing the packages with Yum or the various PackageKit frontends. Any questions or issues with these packages should be directed to the cygwin-ports-general list for now.

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

Across and Back Again

As you may be aware, last summer I added cross-compiling support to cygport, resulting in a new 0.10 series. The results so far have been quite promising, with cygwin-based cross-toolchains now available for the following targets:

• MinGW (i686-pc-mingw32), with the basic packages available here pending an ITA, and many more in Ports
• MinGW-w64 (i686-w64-mingw32 and x86_64-w64-mingw32), already in the distro
• Linux x86 (i686-pc-linux-gnu) and x64 (x86_64-pc-linux-gnu)
• Solaris 10 x86 (i386-pc-solaris2.10) and SPARC (sparc-sun-solaris2.10)
• Solaris 11 x86 (i386-pc-solaris2.11)
  
• AVR microcontrollers (avr)

With this improvement to cygport, cross-compiling from Cygwin comes with the ease you would expect from a Linux distribution.

This week, I decided it was time to turn things around and make it easier to cross-compile to Cygwin as well. To that end, I have created a minimal Linux-to-Cygwin cross-compiler toolchain for Fedora Linux. Under my "fedora-cygwin" (sub)project, I have posted .spec files and patches to SourceForge git and RPMs for both ix86 and x86_64 to the File Release area. For now it is necessary to manually download and install the RPMs until I have the chance to figure out how to setup a yum repository.

While these packages are mostly based on the work of the fedora-mingw project, there are important differences. I'll admit that these are my first RPM spec files, so I'll gladly take constructive suggestions for improvement, or better yet, git patches. Furthermore, these have yet to be tested beyond building themselves. If you do find these useful, or discover any problems, please let me know through the Cygwin Ports mailing list for now.