Re: G-Golf - Callback segmentation fault

Hello David.  Thank you for this important groundwork that g-golf is.

Sorry to say, I have not developed any GUI and had no time as planned.
It will not happen with me.  But Debian is not the problem; all is fine
there (unlike G-Golf on Guix on Debian).

I also failed to put a libg-golf-tests library to actually test gobject
libraries in g-golf’s tests and link it with libtool, but it never
worked, because autotools does not support linking for tests and all
libtool executing would have to be done manually.

The feedback I can give: guile-zlib in its build system autodetects the
location of its needed libz library in configure.ac as LIBZ_LIBDIR,
substitutes that in a config.scm.in module and calls (dynamic-link
%libz) on that path.  If you made g-golf/init.scm do this, it would be
easy on Guix/Nix to build from source.

David Pirotte <[email protected]> writes:
> As i did suggest already, you should ask for some guix highly
> knowledgeable designer/developer (and who deeply knows the other
> involved domains, C, guile's ffi implementation, dynamic libs linking
> ...) - I'd happily stand corrected, and happily patch g-golf if ... but
> till proved wrong, i don't think it is a g-golf problem.

I’m missing an entry point to debug if the problem is
<https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/main/girepository/gitypelib.c>
and do not understand typelibs, except I see the giscanner part of
gobject-introspection needed Nix-/Guix-specific patches:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch

https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/libraries/gobject-introspection/absolute_shlib_path.patch

which I cannot understand at the moment.  I suspect you’d need similar
work.

Then, I see on docs.gtk.org there is a girepository 3.0 (likely a typo
and meant to say 2.0) migration which will make it hard to try the
latest girepository version with g-golf, but also, no version of
girepository 2.0 is packaged for guix anyway.  It seems much movement is
being done there under gobject-introspection’s hood.


>> Intermittently I once saw a different error:
>> ...
>
> I can't make sense of this error, but so you know, vfunc-checks checks
> that the (upstream lib) virtual function you are trying to define in
> g-golf exists in the class you are 'altering', and also checks that the
> scheme virtual function name is correct [1]

So indeed you regard it as unrelated, too.  I tried but wasn’t able to
make any reproducer, because the issue happened no longer; it did not
happen in container isolation.  But the problematic build, that I did
not keep, was isolated.

Could you document this purpose of vfunc-checks in
g-golf/hl-api/vfunc.scm?  Clearly you have put a lot of glib
introspection knowledge in the g-golf implementation that an outsider
would understand only with IRC help.  But it’s the same for
gobject-introspection itself.


> So it disappeared and you can't reproduce it, let's concentrate on
> the (g-golf) virtual function definition bug in Nix/Guix ...

Yes, this is the only real annoyance.

Regards,
Florian