gio modules makes the g* stack non-relocatable

[Paul Davis <paul linuxaudiosystems com>]

in another wrinkle to the continuing general difficulty of relocating
libraries that make up the gtk stack, a new issue with gio...

libgio is hardcoded at compile time to search {prefix}/gio/modules)
for its gio plugins. if an app linked against libgio executes on a
system where {prefix}/gio/modules contains a gio plugin that requires
functionality not present in the *relocated* (ie. private) gtk stack
that the app is using, then gio fails. here is an example:

   "symbol lookup error: /usr/lib/gio/modules/libdconfsettings.so:
undefined symbol: g_settings_backend_get_type"

in this case the app is using a relocated instance of the gtk stack
that doesn't provide g_settings_backend_get_type(), but
{prefix}/gio/modules contains a plugin that expects to be able to use
this. the gtk stack wasn't planning to use that gio module, but was
"forced" to discover it via the hard-coded search path.

more or less all other search paths in the gtk stack can be overridden
with environment variables. for example:

  GTK_RC_FILES
  GTK_LOCALEDIR
  PANGO_RC_FILE
  FONTCONFIG_FILE
  GDK_PIXBUF_MODULE_FILE
  CHARSETALIASDIR

(several of these require creating a file as well as setting an
environment variable, but you get the point).

gio can only supplement the search path (via GIO_EXTRA_MODULES). it
would be nice if it followed the convention(s) of the rest of the
stack, and allowed relocation in this way. a trivial solution would to
use GIO_MODULE_PATH if set in the environment, or {prefix}/gio/modules
etc. otherwise.

comments? i'm happy to provide a patch if the goal is agreed upon.