Maxime Devos <maximede...@telenet.be> writes: > [...] > > However, GIO_EXTRA_MODULES is defined anyways: > > GIO_EXTRA_MODULES=/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/gnu/store/knm6b1dxg2j3vji4wrgngv99pvb6f5ff-glib-networking-2.70.0/lib/gio/modules:/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules:/run/current-system/profile/lib/gio/modules:/gnu/store/8k9s3z2315p494fj937jyvc9v7gpbjr8-dconf-0.40.0/lib/gio/modules
This environment variable is leaked from program wrappers, likely from gdm or gnome-shell. I'm trying to address this in <https://issues.guix.gnu.org/75688>. > [...] > > I think a proper solution would be to make plugin path environment > variables ABI-dependent, or more precisely, store-output-name > dependent (as ABIs are not very practical to keep track of > accurately). > > Take, for example, the glib package, which currently has the > GIO_EXTRA_MODULES path. This could be replaced by > HASH_GIO_EXTRA_MODULES, where HASH is the HASH in > /gnu/store/XXX-glib-2.72.3. > [...] > > Instead of store-output-name-dependent environment variables, an > alternative method would be to make the location of the plugins > store-output-name-dependent. > > More concretely, keep the current name GIO_EXTRA_MODULES and the current > value of $GIO_EXTRA_MODULES, but put libdconfsettings.so into > /gnu/store/[...]-dconf-0.40.0/lib/gio/modules/HASH/libdconfsettings.so > instead of > /gnu/store/[...]-dconf-0.40.0/lib/gio/modules/libdconfsettings.so > and adjust gio to look in this new location. Yes, this could solve ABI problems between incompatible programs and libraries, sound likely doable. I'd try this later, thank you!
