GNU bug report logs - #75157
Grafting inconsistency with multiple outputs is causing problems

Previous Next

Package: guix;

Reported by: Dariqq <dariqq <at> posteo.net>

Date: Sat, 28 Dec 2024 08:54:01 UTC

Severity: important

Merged with 48907

Full log


View this message in rfc822 format

From: Dariqq <dariqq <at> posteo.net>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: 75157 <at> debbugs.gnu.org
Subject: bug#75157: Grafting inconsistency with multiple outputs is causing problems
Date: Sun, 29 Dec 2024 09:30:54 +0000
Hello FLorian,


I think you are experiencing a different (related) issue because the 
problem I seems to vanish by linking to the glib that is used by g-golf 
instead (the --no-grafts options ensures that only one glib is in my 
guix shell)

On 29.12.24 01:24, pelzflorian (Florian Pelz) wrote:
> 
> 
> Both my GLibs have one output only.  I still believe above guix commit
> is the first bad commit for you, as well, and
> 
> guix time-machine -q --commit=78c4d00ab02ab41a22058cdbec0329752e47580f
> 
> will show the error and parent commit
> 
> guix time-machine -q --commit=08e0144d2338c8fb51e52e74274554583d0faa69
> 
> will be fine.  Is it?
> 



The problem i am seeing is still available in 
08e0144d2338c8fb51e52e74274554583d0faa69.


Here is what I've been playing around with:
a simple c file that just loads a scm file.
a simple scm file that just tries to instantiate a gobject class (in 
this example from json-glib but that is irrelevant, using something 
small and simple)

--8<---------------cut here---------------start------------->8---
main.c:
#include <libguile.h>

int
main (int argc, char **argv)
{
    scm_init_guile();
    scm_c_primitive_load("foo.scm");
}

foo.scm:
(use-modules (g-golf))

(gi-import "Json")

(describe (make <json-parser>
	    #:immutable #t))


Build with
gcc -o main main.c \
    `pkg-config --cflags --libs guile-3.0` \
    `pkg-config --cflags --libs gobject-2.0`

Running this with grafts:
 ./main

(process:3071): GLib-GObject-CRITICAL **: 08:50:36.946: 
g_object_new_is_valid_property: object class 'JsonParser' has no 
property named 'immutable'
#<<json-parser> 7f186b2f56d0> is an instance of class <json-parser>
Slots are:
     g-inst = #<pointer 0x1445e900>

(process:3071): GLib-GObject-CRITICAL **: 08:50:36.947: 
g_object_get_is_valid_property: object class 'JsonParser' has no 
property named 'immutable'

(process:3071): GLib-GObject-CRITICAL **: 08:50:36.947: 
g_object_get_is_valid_property: object class 'JsonParser' has no 
property named 'immutable'
     immutable = #f

When not linking to gobject , using no-grafts or running directly from 
guile repl things work as I would expect:
./main
#<<json-parser> 7ff2471f1d20> is an instance of class <json-parser>
Slots are:
     g-inst = #<pointer 0x2bbbe920>
     immutable = #t
--8<---------------cut here---------------end--------------->8---

On 08e0144d2338c8fb51e52e74274554583d0faa69 a similar problem exists:
g-golf depends on the ungrafted out output of hidden glib
but full glib is getting grafted (because of other other outputs)



If I prepend the glib with the single output graft to pkgconfig path and 
rebuild (s.t. my c prgram is linked to the same glib that is used by 
g-golf) things start magically working again.


> I believe what we describe here is yet another symptom of old bug
> <https://issues.guix.gnu.org/48907>, but if we have a first bad commit,
> and if it is the first bad commit for you, too,
> it might help solve it.  Or perhaps this bug can be solved separately if
> really the loading through typelib vs. not through typelib is the cause.
> 

There might be an even bigger issue here?


However regardless of it causing issues I think having 2 different 
grafted glibs (or rather anything) is not really great.

> Regards,
> Florian

Have nice day,
Dariqq




This bug report was last modified 161 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.