Hello David, David Pirotte <da...@altosw.be> writes: > fwiw, g-golf doesn't load/import/invoke/call nor the GdkPixbuf > typelib, nor any of its functions/methods 'on its own', nor > does any example, this occurs as part of the Gtk/Gdk/Gsk > 'engine' - it is not g-golf that 'runs g_typelib_symbol on > GdkPixbuf functions;
I had not known that g-golf does not call g_typelib_symbol. I will have to read more what calls it initially. The initial calls are to a GdkPixbuf path listed in environment variables, later calls are to a GdkPixbuf path referenced in the files that are part of GTK. Yes, Guix should make it so the two are the same. > Fwiw, debian 'generally' has two pkg for 'those situations', one with > the library itself and one for the debug symbols: Guix does the same, but for GTK, it runs a different GdkPixbuf build entirely without debug symbols, with different build steps, therefore a different hash, therefore a different file path. Guix has bug#48907 filed, because debug symbols do not work, that Guix should not create two paths or that debug symbols should work despite Guix doing that. > You (the guix team) should fix Guix, not the g-golf app(s). Yes. >> The second issue is the vfuncs when running >> examples/gtk-4/drawing-widget.scm. This segfaults at >> gtk_widget_snapshot_child when run. This I will investigate firdy. > […] > What about pygobject? pygobject GTK3 examples are working. I will experiment and try to write Vala/C code that breaks now. > 1- fix guix to have one gdk-pixbuf module > 2- let's try to fix the vfunc problem in guix, using the > examples/gtk-4/drawing-widget.scm ... or some even easier vfunc > test code i could write if necessary I will look at 2 in the next days. Regards, Florian
