Hi Florian,

	is your debian host g-golf experience ok? i know it is a
	temporary solution, till we find a solution for nix/guix, but
	i am curious - also, is the app you are working on free s/w,
	any public repo we could look at?

> Hello,  Yes, the same issue still plagues me.  Never tried guile-gi
> and I do not know the difference regarding vfuncs.  Is it like
> pygobject that guile-gi does not use Guile as much and more C?

I just made a comment about guile-gi because Matija did mention it ...
and wanted to make sure they understand guile-gi does not support
virtual function ... but yes, guile-gi is nearly entirely written in C,
and as a matter of fact, largely inspired by pygobject.

> My only progress:
> 
> > I'm using Nix.  
> 
> Interesting.  Guix and Nix have their own settings to load libraries
> according to a sideline comment in [1], but I have no clue otherwise.

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.

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

Thanks,
David

[1] https://www.gnu.org/software/g-golf/manual/g-golf.html#define_002dvfunc