Hi Danny,
On 26.05.25 01:29, Danny Milosavljevic wrote:
Hi Ludo!
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 don't know. Personally, I had never debugged it this far before.
Now, I think this is a very small reproducer!
It is very clear that there should not be two different glib-2*/*.so, but there
clearly are, and both are tried to be loaded.
I have read through the other bug reports now--and an interesting hypothesis is that grafting sometimes only graft the
"out" output of the package, not all the outputs. That could be the case here too--since g-ir-* tools
(generators of typelibs etc) are likely in the "bin" output and the ".so" files are in the
"out" output.
These are the 2 dervations:
/gnu/store/syrd2334kzgd385xpbyqw78avnnc8jfb-glib-2.82.1.drv
Found in the output of 'guix build python-pygobject -d'
This one only grafts the out output to
/gnu/store/fvfzcrgkn4jvqafhrzm8a6kwxzdjpz72-glib-2.82.1
/gnu/store/pg696sxm0pk2j1fw49izi9hdn62lnln6-glib-2.82.1.drv
This is "guix build -e '(@@ (gnu packages glib) glib)' -d"
This one produces all 4 grafted glib outputs (bin, debug, out, static)
in one derivation with the out output of
/gnu/store/wx0xwypxpgcwa47grr2wgpcdiaws6wfc-glib-2.82.1
So the problem of the 2 glibs is that after grafts python-pygobject has
a reference to the first glib but the main glib that is also in your
profile gets grafted to a different one, similar to my issue with g-golf
in #75157.
Dariqq
