Re: Directory for .gir (gobject-introspection) files? (Multi-Arch)
- Date: Sun, 17 Feb 2019 00:18:54 +0100
- From: "W. Martin Borgert" <debacle@xxxxxxxxxx>
- Subject: Re: Directory for .gir (gobject-introspection) files? (Multi-Arch)
many thanks for taking the time to go through this bug report!
Very much appreciated!
On 2019-02-16 17:02, Simon McVittie wrote:
> Multiarch-qualified directories under /usr/share don't seem like they make
> much sense: the whole point of the $libdir/$datadir duality is that if
> files need to be different on some architectures, then the files should
> be in $libdir, not in $datadir.
> My understanding is that GIR is intended to be a collection of
> machine-readable facts about the source code, rather than facts about
> the binary, which is why it's in /usr/share in the first place (unlike
> the typelib, which is architecture-dependent). However, those facts are
> partially derived from inspecting the binary, so can in principle end
> up different in rare cases, and presumably that is what's happened here.
(Just for myself in order to not forget it,) the six
GLib-2.0.gir variants are:
- armel, armhf, i386, mipsel
- arm64, mips64el, ppc64el
The differences are e.g. in how/whether GDoubleIEEE754,
GFloatIEEE754, G_VA_COPY_AS_ARRAY, GLIB_SIZEOF_LONG (4 vs 8
bytes), GUINTPTR_FORMAT (lu vs. u) etc. are defined.
Btw. Peter Pearse of Linaro found similar issues in 2011:
"Investigation of gobject introspection with a view to cross
The differences he found in Clutter-1.0.gir seem to be solved now,
the GLib-2.0.gir differences not.
> The program that generates GIR (g-ir-scanner) is architecture-independent
> Python code, so it's easy to say "gobject-introspection should look in
> its own $libdir/gir-1.0 in addition to $XDG_DATA_DIRS/gir-1.0", but
> probably harder to actually implement than you might think.
I found only one .gir file under $libdir in sid, only for ppc:
> One option for fixing this for buster, if it is considered to be urgent,
> is to investigate what the difference is and whether it can be eliminated,
> perhaps by wrapping the code that differs between architectures in
> #ifndef __GI_SCANNER__.
Sorry, here you lost me: In which code do you like to see the
conditionals? In glib?
> Another is to remove the M-A: same annotation.
I like to be able to cross-build certain packages. For my
usecase, I have to install libgirepository1.0-dev for multiple
architectures, because the package depends on it.