GNOME Bugzilla – Bug 634045
Request runtime influence over GIO_MODULE_DIR
Last modified: 2013-11-23 06:42:08 UTC
Created attachment 173859 [details] [review] Override GIO_MODULE_DIR via environment variable Scenario: When redistributing GLib 2.24.0 with a piece of software and installing on target host having GLib 2.24.1+, software linking against Glib 2.24.0 crashes during initialization after loading incompatible GIO modules from hard coded path of /usr/lib/gio/modules. Would it be possible to alter GLib/GIO to allow influence over the GIO modules directory at runtime? I'm aware of GIO_EXTRA_MODULES, which is fine for finding supplementary modules, but in this case I'm trying not to load the base modules. Attached is a trivial patch I whipped up to deal with this.
Can someone please take a look at this? It's been 2+ years and we're still shipping a patched glib. I'd love to not have to do that anymore.
If you're distributing that piece of software with a custom GLib then why not specify -DGIO_MODULE_DIR when compiling it?
(In reply to comment #2) > If you're distributing that piece of software with a custom GLib then why not > specify -DGIO_MODULE_DIR when compiling it? The target install directory is chosen by the user at install time, so to do that would mean compiling with something like -DGIO_MODULE_DIR=\"/nonexistent\"¹, and then relying on GIO_EXTRA_MODULES. But why? Is there a good reason _not_ to support this?² (If it's a bad idea, hey, no worries -- an update / explanation / resolution from GLib dev is all this bug needs.) FWIW, GIO on Win32 searches for GIO modules relative to gio.dll, so there's some sort of precedent in the GLib codebase for loading a path determined at runtime. 1. /nonexistent exists on FreeBSD, so one would have to pick something else. 2. Considering https://mail.gnome.org/archives/commits-list/2012-September/msg06538.html, the patch should probably include a call to g_check_setuid() before searching _any_ environment-derived path (GIO_MODULE_DIR or GIO_EXTRA_MODULES).
It seems a bit weird to ship a bundled glib built with a /usr prefix which is then installed in a different place. On the other hand, I don't think there is any problem with allowing it (sans for the setuid case), as it does help you make things relocatable, and should not affect performance.
(In reply to comment #3) > (In reply to comment #2) > > If you're distributing that piece of software with a custom GLib then why not > > specify -DGIO_MODULE_DIR when compiling it? > > The target install directory is chosen by the user at install time, so to do > that would mean compiling with something like > -DGIO_MODULE_DIR=\"/nonexistent\"¹, and then relying on GIO_EXTRA_MODULES. FWIW I do something like this in: http://git.gnome.org/browse/ostree/tree/embedded-dependencies/Makefile.am But I don't use (or in fact, want) gio modules in the embedded dependency build.
Well, not wanting or wanting some other subset is more or less the same situation (just point it at your empty dir)
Sigh... Closing as a duplicate of the future bug. At least this finally got merged. *** This bug has been marked as a duplicate of bug 711801 ***