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.
In my case here, this problem is 100% reproducible and I don't do stuff like
referring to a package by package name in a manifest to cause it (anymore).
In fact, a manifest with just my (inlined) package in the manifest is enough
for it to happen! I just tried.
And: Indeed, as you suspected, the following is also enough (no manifest.scm at
all! And it still happens):
$ guix shell -D -f guix.scm --pure --rebuild-cache
(env)$ ls
guix.scm mini.py
(env)$ cat guix.scm
(use-modules (guix packages))
(use-modules (guix gexp))
(use-modules (guix build-system pyproject))
(use-modules (gnu packages glib))
(use-modules (gnu packages gtk))
(define %source-dir (getcwd))
(define-public m3
(package
(name "m3")
(version "FIXME")
(source (local-file %source-dir
#:recursive? #t))
(build-system pyproject-build-system)
(arguments
(list #:tests? #f))
(propagated-inputs
(list python-pygobject gtk+))
(synopsis "m3")
(description "FIXME")
(home-page "FIXME")
(license #f)))
m3
(env)$ cat mini.py
if __name__ == "__main__":
import os
import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk
win = Gtk.Window()
win.connect("destroy", Gtk.main_quit)
win.show_all()
Gtk.main()
(env)$ python3 mini.py
Traceback (most recent call last):
File "/home/dannym/src/material-ex/m4/mini.py", line 12, in <module>
win.connect("destroy", Gtk.main_quit)
TypeError: <Gtk.Window object at 0x7f7f3fb33400 (GtkWindow at 0x39509850)>:
unknown signal name: destroy
Segmentation fault
$ /home/dannym/.guix-home/profile/bin/strace -f python3 mini.py 2>&1 |grep
glib- |grep -v ENOENT |grep libgobject
openat(AT_FDCWD,
"/gnu/store/fvfzcrgkn4jvqafhrzm8a6kwxzdjpz72-glib-2.82.1/lib/libgobject-2.0.so.0",
O_RDONLY|O_CLOEXEC) = 3
newfstatat(AT_FDCWD,
"/gnu/store/wx0xwypxpgcwa47grr2wgpcdiaws6wfc-glib-2.82.1/lib/libgobject-2.0.so.0",
{st_mode=S_IFREG|0555, st_size=400744, ...}, 0) = 0
openat(AT_FDCWD,
"/gnu/store/wx0xwypxpgcwa47grr2wgpcdiaws6wfc-glib-2.82.1/lib/libgobject-2.0.so.0",
O_RDONLY|O_CLOEXEC) = 3
Clearly, there should not be two different hashes here.
("grep libgobject" only done for clarity--it happens with some other libraries
in glib as well)
(env)$ env
SHELL=/gnu/store/nsvknyc47xrja968n7g9llcdrfixhzj4-bash-5.1.16/bin/bash
OBJCPLUS_INCLUDE_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/include/c++:/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/include
HISTSIZE=
GUIX_PYTHONPATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib/python3.11/site-packages
XCURSOR_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/share/icons
GUIX_GDK_PIXBUF_MODULE_FILES=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
PWD=/home/dannym/src/material-ex/m4
LOGNAME=dannym
GI_TYPELIB_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib/girepository-1.0
HOME=/home/dannym
TARGET_HOSTSPEC=d...@atrium.eng.oxide.computer
GIO_EXTRA_MODULES=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib/gio/modules
OBJC_INCLUDE_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/include
TERM=foot
CPLUS_INCLUDE_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/include/c++:/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/include
USER=dannym
LIBRARY_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib
DISPLAY=:0
SHLVL=1
GUIX_LOCPATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib/locale
PAGER=less -F
GUIX_ENVIRONMENT=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile
PREV_COMMAND=
XDG_DATA_DIRS=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/share
PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/bin:/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/sbin
C_INCLUDE_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/include
VDPAU_DRIVER_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib/vdpau
GUIX_GTK3_PATH=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/lib/gtk-3.0
_=/gnu/store/3646wxph13zvx0iw4n86scvchfwmdknz-profile/bin/env
If I can help debugging and fixing this, I will gladly do so.
How can I manually try grafting steps (or enable verbose logging of what
outputs exactly of what were grafted)?
If I knew that, I could continue to figure out where exactly it went wrong.
And how can make it do the grafting of stuff it has already done (and cached)
again (for debugging)? I suspect guix gc and then retrying would do it--but
something more targeted...
I feel like I'm like one step away from seeing the root cause...
Also, I *thought* I would need the following fix, but it seems to be not
required. How come??
In "define gobject-introspection" (especially the bottom glib "bin" thing):
+ (native-search-paths
+ (list
+ (search-path-specification
+ (variable "GI_TYPELIB_PATH")
+ (files '("lib/girepository-1.0")))))
+ (search-paths native-search-paths)
(native-inputs
(modify-inputs (package-native-inputs base)
- (replace "glib" glib)))
+ (replace "glib" `(,glib "bin"))))
I also did some LD_DEBUG=libs to get further info, but it's not that
interesting. It seems that the initialization (not the dlopen) of the other
glib fails (lots of unknown symbols !?). Other than that, uneventful (and very
long).
I found an old bug report that states that our grafter searches for the hash
part but then overwrites everything (also stuff after the hash part). That
seems like something very very bad and could easily damage shared objects.
https://issues.guix.gnu.org/47838
