Just curious, what's wrong with glib? I happen to like it a lot, and it's a good option for getting access to data structures that other languages take for granted.
Also it leads to GObject abuse which is harmful to the soul.
Ultimately, the moment you bring glib into a project it stops being C, much like the Win32 API does.
I'd rather pull in libapr and apr-util.
Say what you will, but I see the book's apparent inclusion of glib as a plus.
I used to work at MS and grew very comfortable (and appreciative) of the stylistic choices in the NT kernel (distinct from the Win32 style, one key difference is much less Hungarian notation). But I can jump back into more typical-of-*nix styles with ease. Or the more Win32 style if preferred. I think it's important to see the merits and drawbacks of various style decisions in a non-judgmental fashion, and be able to switch back and forth depending on the code base you're working in. It's a mistake to confuse style and convention with "not being real C". Different doesn't mean not real.
I haven't checked recently, but the problem with APR was for so many years it had (possibly still has) no documentation other than Doxygen. Also, the memory pool design seemed an enormous complication. Have you used it recently and have either of those factors improved much?
GObject is a bit different matter - there's quite a bit of boilerplate, which makes me think twice before adding one. But at the same time, it's quite nice to use them in libraries like GStreamer.
GLib is certainly not perfect, but I found it more pleasant to use than, say, talloc. Are there any specific advantage is APR? (I've never used it) Does it cover the same functionality?