[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64836: pygobject GTK modules lookup fails following CUPS graft
From: |
Maxim Cournoyer |
Subject: |
bug#64836: pygobject GTK modules lookup fails following CUPS graft |
Date: |
Tue, 25 Jul 2023 11:35:23 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi,
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hello,
>
> I initially thought the issue may be with the GTK .typelib files not
> getting grafted correctly, but I've verified them and they appear
> correct (there's a single file name for the shared library, and it
> appears in the .typelib in full, gets grafted correctly).
>
> So I'm now leaning toward a different explanation: wxWidgets or wxPython
> retaining a reference to the ungrafted GTK library, loading it first,
> then pygobject attempts to load the grafted GTK, and both conflict,
> producing error messages such as "Warning: cannot register existing type
> 'GtkWidget'".
>
> I'll now attempt to verify this potential cause.
I think I might have found something fishy; python-wxpython appears to
keep references to unexpected wxwidgets outputs, unless I am
misunderstanding how grafts appear.
Consider, for guix 21b718f:
--8<---------------cut here---------------start------------->8---
$ guix build wxwidgets
/gnu/store/dkj98zg7d7ijxiyymjxr6l4z2qb71cq4-wxwidgets-3.2.2.1-debug
/gnu/store/40a6chmcvn99dbz1vy16fy88bzfb6bj3-wxwidgets-3.2.2.1
$ guix build --no-grafts wxwidgets
/gnu/store/08mx5x1sblzb39ng9bj5ly2pibxzyx4s-wxwidgets-3.2.2.1-debug
/gnu/store/cm3pyzm7h8h3s4rxdcrfd1qhsby7g911-wxwidgets-3.2.2.1
--8<---------------cut here---------------end--------------->8---
The grafted version of wxwidgets is
'/gnu/store/cm3pyzm7h8h3s4rxdcrfd1qhsby7g911-wxwidgets-3.2.2.1', which
is the one I'd expect the grafted python-wxpython to refer to, but:
--8<---------------cut here---------------start------------->8---
$ guix build python-wxpython
/gnu/store/2fbdcwsif1ihb5ig3smcp4g79dh7wxwy-python-wxpython-4.2.0-debug
/gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0
$ guix gc -R /gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0
| grep wxwidgets
/gnu/store/nj48sl6wdqh4m4yp8g8r04bx0mxmqfv3-wxwidgets-3.2.2.1
--8<---------------cut here---------------end--------------->8---
i.e. it refers to a different wxwidgets, which is not the above grafted
nor the ungrafted version (!?).
A grep such as
--8<---------------cut here---------------start------------->8---
grep --include='*.so' -rn --text wxwidgets-3.2 \
/gnu/store/v4xz45cwj88p3l6x1nmvxwg0yrcsg7hd-python-wxpython-4.2.0
--8<---------------cut here---------------end--------------->8---
Indeed reveals that the only wxwidgets referred by the shared library
objects is /gnu/store/nj48sl6wdqh4m4yp8g8r04bx0mxmqfv3-wxwidgets-3.2.2.1.
What is going on here? Or is this expected and my understanding of how
grafts work flawed?
--
Thanks,
Maxim