Friday, December 2, 2011
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.
Thursday, December 1, 2011
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:
- the plugin init functions are marked __attribute__((constructor)), a GCC extension which causes the indicated function to be called automatically;
- the plugins rely on symbols in the main binary, of course, but furthermore...
- the executable also relied on symbols in the vnc plugin, and to top it off...
- the executable is linked against the plugins!! (If you don't think you misread that, then try again.)
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.
Wednesday, July 6, 2011
Sunday, July 3, 2011
Saturday, March 12, 2011
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.
Friday, March 11, 2011
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).
Thursday, February 17, 2011
- 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)