Re: gio modules makes the g* stack non-relocatable

[Matthias Clasen <matthias clasen gmail com>]

On Tue, Oct 18, 2011 at 7:33 AM, Paul Davis <paul linuxaudiosystems com> wrote:
> 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.
>

Not sure how I feel about the idea of relocated stacks not providing
the full glib api, but having an environment variable to override the
location of gio modules seems fine to me.