Welcome Aboard

In response to a recent inquiry on the cygwin list, I now have Ruby on Rails working out of the box on Cygwin, and have just uploaded the necessary packages to the Ports repository. To assure proper operation, the newly updated Ruby 1.9.3-p385-2 release is required.
To get aboard with Rails, install the ruby-rails package and its dependencies, then:

$ rails new testapp1 --skip-bundle
(files are installed)
$ cd testapp1
$ bundle install --local
(this will show that existing gems are being used)
$ rails server

(then point browser to http://localhost:3000/,
OR:)
$ unicorn_rails
(then point browser to http://localhost:8080/)

From there on out, you're on your own. Enjoy the ride!
UPDATE: Well, that didn't take long. A security advisory was issued yesterday for Rails, so I have updated the Rails packages to 3.2.12 accordingly. The supported method for updating Rails apps for newer Rails versions is as follows:

1. Open Gemfile in a text editor and update the version number following the gem 'rails' directive.
2. Run bundle update --local to update the Gemfile.lock file. Existing gems should be found and used.
3. Run rake rails:update to update configuration files, using the 'd' option to verify changes first.

More details on this procedure are available on RailsApps.

X doesn't always mark the spot

I have added X11 proto and library packages for the Win32 (i686-w64-mingw32) cross-compiler stacks on both Cygwin and Fedora, as well as for the i686-Linux (i686-pc-linux-gnu) stack on Cygwin. This means that it is now possible to compile-test xserver patches for Linux, Cygwin, and MinGW at the same time from one platform.

Unfortunately, building X11 for Win64 (x86_64-w64-mingw32) is going to take more work. Win64 is unique among 64-bit platforms in being LLP64 (32-bit long, 64-bit long long, 64-bit pointers), which breaks the assumption throughout the X11 codebase that a pointer can be cast to a long (which works on other platforms, both 32- and 64-bit). The usual solution to this is intptr_t, but that is C99 and hard requirements thereon are generally avoided in the X11 codebase. Hence, solving this will require massive patching to the headers (possibly including the addition of a intptr_t-like type), and will need to be discussed thoroughly in advance by interested parties.

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.

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.

New website

While SunSite.dk has been an accommodating host of an ever-growing Ports repository, recent issues with downtime, responsiveness, and storage limits (albeit generous) have held up progress over the last few months. While I am grateful for all their help, the time has come to find another home.

Thanks to the graciousness of a sourceware.org admin, Cygwin Ports has found a new home for the website and package repository. This will allow for easier updating and continued expansion of Ports' offerings. The sunsite.dk package repository has been removed, and all website links now point to our new home.

I invite all Ports users to visit the new website, and follow the directions there to update their packages. As always, questions/comments/issues/testimonials/thanks/etc. go to the cygwin-ports-general list.

Netscape plugins

What does Netscape have to do with Cygwin, you ask? Didn't I just say that anything Mozilla-related doesn't work yet on Cygwin?

Fortunately we still have one working browser on Cygwin: Konqueror. The nsplugins package allows Konqueror to load and use Netscape-compatible plugins. At the next upload, there will be two such working plugins: DjView3 and Xine. I tried, but failed, to get swfdec-mozilla 0.5 working as well; another try with 0.6 will have to wait for GNOME 2.22.

Yes, swfdec itself and the swfdec-gnome player are working, but I had to disable sound support. Enabling the OSS sound support would lock up video playback while the audio was playing. In the meantime, at least it works for games.

If you're looking to play YouTube videos within Cygwin, a recent Linux.com article lists several downloaders. FFmpeg support allows the following applications to play the FLV videos: ffplay (ffmpeg), gxine, kaffeine, kmplayer, kplayer, mplayer, totem, vlc, xine (xine-ui).

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.

KDE and gamin

In the Ports builds of KDE 3.5.8, I enabled FAM (with gamin) support in kdelibs. Unfortunately, the tradeoff has been excessive CPU usage by gam_server, much more than is normal with GNOME. Some googling showed that this may not be unique to Cygwin, but can happen on Linux as well. While I'd be interested to hear if anyone has noticed any positive effects from the FAM support, at this point, I think I'm going to have to rebuild kdelibs without it.

SECURITY: link-grammar

A security vulnerability has been announced for link-grammar. A version bump to fix this is in CVS, and will be included in the next upload.

PHP on Cygwin

Efforts to bring PHP to Cygwin have waxed and waned over the years. One of the big problems, at least with PHP5, was dealing with shared extensions, as discussed last year in this thread. Unfortunately the sources mentioned there are no longer available, so unfortunately I didn't even have that to start with.

PHP consists of multiple interpreters (called SAPIs) which serve different purposes, e.g. a command-line interface, a CGI interface, Apache modules, etc., together with dozens of extensions written in C, which can either be built in to the interpreter or can exist as loadable modules. Additional C extensions are also available on PECL, which must be built as shared modules, as they are installed after building the runtime.

PHP extensions require symbols that would normally be (on Linux) in the interpreters, but that doesn't work for Cygwin because all symbols must be resolved at link time. But if an extension is linked against one SAPI but loaded by another, a segfault will result.

The solution is, as is done with MSVC, is to build almost all the core sources into a shared library, then link the SAPIs (with just their SAPI-specific code) and the extensions against the library. Implementing this within the autotool framework took a lot of work to get right, but it looks promising so far: both the CLI and CGI load all the modules, PECL extensions can be built, and even better, PHP-GTK is working.

This solution does require a few minor changes to the build procedure for PECL extensions, hence I've added php.cygclass to cygport for this purpose; in most cases, a one-liner 'inherit php' is enough.

PHP, PHP-GTK, and several other sample PECL extensions are now in CVS; the PHP .cygport is heavily commented, which should help make sense of what was needed to make this work, for those who are interested. PHP, with separate packages for each of the standard extensions, as well as PHP-GTK, will be available in binary form with the next upload.

BTW, at this point I have no intention of packaging PEAR (pure PHP extension) libraries, as they require no compilation; instead, just install php-pear and install them as on any other platform.

If anyone is running Apache, then I would like to hear if those SAPIs are working; please post a comment below or to the mailing list.

Enjoy!

SECURITY: libsndfile

The Gentoo Security team has announced a security vulnerability in all versions of libsndfile. I have rebuilt libsndfile with their patch, as well as for the new FLAC API. This is now in CVS, and will be included in the next upload.

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.