Hi Danny, Danny Milosavljevic <dan...@friendly-machines.com> writes:
> There are multiple definitions (same package version) of the packages glib > (and gobject-introspection and python-pygobject), in the same Guix repo. So > far okay. > > But if you aren't very very careful [so basically always], you end up with > different versions of glib in the same profile (even when using "guix shell > --pure" and a manifest) and, eventually, in the same process. glib (and > GNOME in general) cannot handle that. It's just the way the gobject system > works, it assumes that there's just one of each library (and for that matter > class, interface etc). The libraries register into a global gobject > (reflection) system--and if there are two different registries (in two > different libraries) then all hell breaks loose. (for understanding: Guile's > module system assumes the same--and so does Python's). Debugging those > problems is a nightmare. > > Really, we should make some way in Guix to prevent this from happening for > good. In general that won’t happen if you run ‘guix shell -D the-package-you-hack-on’; you have to explicitly list packages by name to experience this problem. (Which is not to say it’s not a problem.) > Create manifest.scm: > > (load "guix.scm") I’d recommend ‘guix shell -D m3 --export-manifest > manifest.scm’. > What is going on? Why are there two different glib references, one in the > typelibs (presumably the wrong one--see below) and one in the .so files? I think this typelib issue is exactly what was reported a couple of years ago, as you wrote. How is this different this time? What was the resolution last time? I found these related issues: https://issues.guix.gnu.org/75157 https://issues.guix.gnu.org/49122 https://issues.guix.gnu.org/49198 (Cc’ing John who apparently had a fix, above.) Looks like there’s a need to team up to address this one! Thanks, Ludo’.
