I had some trouble compiling gettext, but I did not see
that as the issue, rather glib's dependency on gettext. I'm not sure
if glib should have any dependencies. With enough effort you can get
anything to compile on any system. For me it was gettext, for someone
else maybe iconv, for someone else maybe some other dependency that is
already installed on my system.
I think the value of glib, to developers not creating a gtk+ program,
is in the data structures it provides. Good, stable, implementations
of lists, arrays, hashes, binary trees, etc. I also find the portability
macros useful. If you are writing a gtk+ program, it doesn't matter
because you need everything anyway.
So this low-level core library requires gettext, and iconv and all of
this Unicode manipulation functionality that isn't needed to implement
a good linked list or g_malloc or a gint32.
I think I'm starting to ramble, so I'll just end with..
I think glib has strayed somewhat from being a low-level core library
with the inclusion of unicode handling for one and possibly other
features. My point is _not_ that these features are not useful, just
that glib would be a better library with a more strict focus and useful
to more developers if some of this functionality were moved to a
separate library. This would make glib leaner and easier to compile
(with fewer dependencies), and hence more portable.