I’m setting up a virtual machine using VirtualBox on Ubuntu Gutsy, running Win2000 as the guest OS. I’ve gone and installed Cygwin and MinGW and MSYS in order to build Gnash on Win32. I came across a funny bootstrapping problem trying to install pkg-config: pkg-config 0.22 requires glib 2.x in order to compile. No sweat, I go and download glib 2.13.6 and configure it … and the configure script stops with an error when it can’t find pkg-config installed!
Circular dependencies suck.
Of course, in the README.win32 for pkg-config, Tor Lillqvist acknowledges this at the end of the document:
On Unix, pkg-config is built using its own copy of GLib 1.2.8. On Windows, we use the normal GLib available for Windows (2.0.x). Yes, this does introduce a kind of circular dependency. But, that can be worked around. The circular dependency only appears if one uses the configure mechanism to build GLib. GLib’s configure script checks for pkg-config. pkg-config depends on GLib. Thus, starting from scratch, with no GLib and no pkg-config, using configure, there would indeed be a Catch-22 situation. However, GLib can be built just fine using the manually written makefiles for mingw or MSVC. And if somebody does want to build GLib on Win32 using configure, she can first install a prebuilt pkgconfig.
Unfortunately, as of glib 2.13.6 at least, only the automake files are included–no ordinary makefiles for Win32, either MinGW or MSVC, even. Fortunately, older releases of pkg-config source are still available, and glib 2.13.6 will build with pkg-config 0.14 or newer. pkg-config 0.14 includes glib 1.2.8 and tries to build it as part of its build, so I went ahead and tried to build pkg-config 0.14. Since nothing is ever easy, I ended up having to make a slight change to glib 1.2.8 to get it to compile, adding these lines to the top of glib.h, after the #include <glibconfig.h>:
#define G_MAXINT 0xFFFF
#define SIGCHLD 17
#define g_ascii_strcasecmp(a, b) strcmp(a, b)
I also discovered that gthread.o wouldn’t compile right due to some libtool weirdness, so I had to compile everything somewhat manually with this:
$ cd glib-1.2.8/gthread
$ gcc -I.. -DHAVE_CONFIG_H -DG_OS_WIN32 -o gthread.o -c gthread.c
$ touch gthread.lo
$ cd ..
$ make libglib.la
$ cd ..
$ make CFLAGS="-DG_OS_WIN32" parse.o
$ make pkg-config.exe
$ cp pkg-config.exe /mingw/bin
After all that, I finally had a compiled and installed pkg-config 0.14! I went ahead and used it to build glib 2.13.6 and installed that, then went and built pkg-config 0.22 with it.
So, which came first? The chicken or the egg?
What have I been furiously hacking on the last few nights? Gnash, the GNU Flash player. Specifically, I’ve been doing a lot of hacking on support for Win32. More specifically, I’ve been working on npgnash, the plugin that embeds Gnash inside Firefox using the Mozilla NPAPI.
I’m not going to get into the ugly details of what I went through to get as far as I have, but I’ll summarize it as: a hell of a lot harder than it ought to have been. I’ll save my rant for why C++ sucks, so badly, for another day. What you really want to see are screenshots, I know!
First, here’s the entry for npgnash from Firefox’s about:plugins page:
Okay, big deal, so I can load a DLL. Here’s npgnash playing gravity.swf from the Gnash testsuite, right in the browser:
Who doesn’t love a big bouncing smiley-face animating across their browser, right? But, the true test is playing my favorite YouTube video … to test with, at least:
Yup, that’s no joke … it’s a screenshot of npgnash playing a YouTube video inside Firefox 188.8.131.52 on my WinXP machine. It’s using the Anti-Grain Geometry (AGG) rendering engine, along with SDL/ffmpeg for audio … and they both work, albeit not very well, yet. Still, not bad for three or four days of hacking, right?
Despite all this progress and these screenshots, it’s still not ready for general-purpose use, yet. The underlying Gnash code is still isn’t fully re-entrant/thread-safe and the cleanup code isn’t fully baked so I can’t even load one SWF after another without it crashing. I also haven’t implemented any mouse/keyboard support, so you can’t actually use any of the player buttons you see in the YouTube video, etc., yet.
Still, it’s a great start and hopefully by the time the 0.8.3 release is ready in a few months, there will be a lot more forward progress.