pkg-config and glib, chicken and egg, same thing

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>:

#undef G_MAXINT
#define G_MAXINT 0xFFFF
#define SIGCHLD 17
#define g_ascii_strcasecmp(a, b) strcmp(a, b)
#include <fcntl.h>
#include <winsock.h>

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
$ 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? :-)

Tags: , , ,


  1. So, which came first? The chicken or the egg? :-)

    That’s easy. The egg.

  2. Jeff: LOL! Thanks – that’s awesome. And, I just realized that John Kovalic even has a LJ. Yay!

  3. Great workaround!
    With 0.23, glib.h seems to need also:
    #define g_ascii_toupper(a) toupper(a)

  4. Hi Dossy,
    Thanks for the tip, it worked for pkg-config. When I compile GLib 2 after that, I get all sorts of warnings, do you think I should tweak the files accordingly, or just let live ? Examples:
    .libs/lt-unicode-normalize.c:79:3: attention : passing argument 2 of ‘execv’ from incompatible pointer type [enabled by default]
    c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/process.h:118:42: note: expected ‘const char * const*’ but argument is of type ‘char **’
    .libs/lt-unicode-normalize.c: In function ‘xstrdup’:
    .libs/lt-unicode-normalize.c:95:19: attention : incompatible implicit declaration of built-in function ‘strcpy’ [enabled by default]
    Thank you,

    • I wouldn’t worry too much about the warnings. The fact that it even compiles at all on Win32 is a miracle, for the most part.

      • You’re absolutely right. I am thinking about installing Linux on a PC and learn about this wonderful OS but I still like Windows, so I will keep them both. Thanks again for your advice.

Speak Your Mind