Hello again. This is a bug in Guix territory; not your g-golf. I have
successfully run gtk-4/hello-world.scm, fully responsive, apparently by
running “guix shell --no-grafts” with with-debug-info transformations,
instead of “guix shell” as before, and then broke it again, when I
changed guix.scm again.
drawing-widget.scm continued segfaulting, even during the time when
hello-world.scm worked. I will look at it later, once I’ve
re-repaired my environment to run hello-world.scm again.
I will investigate further in container isolation with no impact from
the environment. I want to debug how to use it properly or where to
patch Guix’ g-golf package.
My hope was you knew debugging tricks. After fruitless debug attempts
with Guile’s ,trace meta-command, I began attaching GDB to Guile, where
I then run
scheme@(guile-user)> (getpid)
$1 = 954
scheme@(guile-user)> (setenv "G_DEBUG" "fatal-warnings")
scheme@(guile-user)> (load
"/home/florian/src/g-golf/examples/gtk-4/hello-world.scm")
scheme@(guile-user)> (main '("guile"))
and in gdb look at the backtrace. However, I did not manage to make gdb
get access to Guix’ pre-built debug info for glib and libffi yet.
(Actually, I had not known GTK4 still depends on GdkPixbuf and has not
subsumed it, but gdb debugging shows it in its backtrace.)
I’m rarely on IRC and prefer asynchronous communication.
The Adwaita hello-world fails in the same way as GTK hello-world (and
thank you for advising me to use Adwaita; I did not know it is a good
idea to use it over plain GTK).
Thank you for confirming the real error is this
> (hello-world.scm:12627): GLib-GObject-CRITICAL **: 23:59:51.067:
> cannot register existing type 'GdkPixbuf'
The warning when not running d-bus
(guile:3310): Gtk-WARNING **: 17:06:29.832: Unable to acquire session
bus: Failed to execute child process “dbus-launch” (No such file or
directory)
occurs for gnome-calculator as well and is not fatal to it. Also it,
strangely, disappeared for g-golf’s hello-world.scm, at the time when it
worked.
There are no per-package services in Guix, so it cannot be guaranteed
d-bus is running everywhere (and missing d-bus is not fatal). I did
try in a Guix System’s GNOME desktop environment and D-Bus and
something A11Y run there by default. But the GdkPixbuf error was
still present.
I tried to run make check, but could not get past configure, see below.
But note that Guix’ g-golf package also runs make check successfully as
part of building g-golf, but in an isolated non-graphical different
environment. To try, I omitted already built g-golf from guix.scm again
and
$ guix shell --no-grafts #load guix.scm
$ guix shell gtk+@3 --no-grafts
$ cd ~/src/g-golf
$ ./autogen.sh
florian@florianrock64 ~/src/g-golf [env]$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running:
/gnu/store/3ddp6zriaxnqxb7qig1y2n0gqfmx7qid-autoconf-2.69/bin/autoconf --force
configure:4908: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf:
/gnu/store/3ddp6zriaxnqxb7qig1y2n0gqfmx7qid-autoconf-2.69/bin/autoconf failed
with exit status: 1
Now run ./configure [--prefix=/your/prefix] [--with-guile-site]
$ ./configure --with-guile-site
configure: error: cannot find install-sh, install.sh, or shtool in build-aux
"."/build-aux
But the g-golf Guix package does run configure and make check
successfully after some workarounds. Their log file is at
https://bordeaux.guix.gnu.org/build/c6bd0e09-70cc-4b78-8b78-808b6bb9d9b1
https://ci.guix.gnu.org/build/3767854/details
for both of Guix’ two build farm’s.
Regards,
Florian
