Especially not now with --disable-modules.

Pass the -I options needed in CPPFLAGS, not CFLAGS.  Explicitly
disable dynamic loading of loaders. Pass an explicit list of loaders
to build in statically. Do include the jpeg loader.

Patch out the chunk of GLib's configure script that looks for
libintl. Take care of fallout in a couple of places in GLib
sources. The end result is that GLib doesn't use any libintl (gettext
etc) functionality. Which is nice, as we then shouldn't need to build
gettext. No functionality should be lost, as we weren't delivering any
GLib message catalogs anyway, so none of the gettext calls at least
here would ever have found any localised messages.

Conflicts:
	graphite/graphite2-0.9.2.patch

Pass --build and --host options to the configure script. Pass a bunch
of a priori cached test results for stuff that can't be determined
when cross-compiling. Link with the CoreFoundation framework. Build
static archives.

Patch out the compile-time USE_LIBICONV_GNU and _LIBICONV_H test from
gconvert.c as it for some reason fails for iOS.

It is needed in case a native internal GLib build is used when
cross-compiling GLib.

We would need to pass -DGR2_STATIC when compiling graphite-using code
otherwise.

Also make patch apply without fuzz.

Just use a config.h geneated for Mac OS X for now, tweak later if
necesssary.

I don't know if this is the right thing to do. The --disable-python
switch is documented to "Disable build of Python 2.x UNO API". Does
that mean that it should disable use of Python at run-time completely?
What about use of Python tools at build-time, do we have such? Will
--disable-python then disable their use, too?

Don't use the same name for the GLib DLLs that we build with MSVS9 as
in the "official" MinGW-built packages (either the ones from
www.gtk.org, or the ones from OBS). The "official" GLib DLLs use
msvcrt.dll, while the ones we build use msvcr90.dll. We want to avoid
potential confusion. Call the DLLs we build glib-2.0.dll etc, not
libglib-2.0-0.dll etc.