On Sun, 17 Feb 2019 at 00:18:54 +0100, W. Martin Borgert wrote: > (Just for myself in order to not forget it,) the six > GLib-2.0.gir variants are: > > - amd64 > - armel, armhf, i386, mipsel > - arm64, mips64el, ppc64el > - hurd-i386 > - mips > - s390x > > 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.
I suspect those should perhaps just not be in the GIR - they aren't really information that is going to benefit a program in Python or JavaScript. > On 2019-02-16 17:02, Simon McVittie wrote: > > 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: > > /usr/lib/powerpc-linux-gnu/mutter/ClutterX11-1.0.gir > /usr/lib/powerpc-linux-gnu/mutter/Clutter-1.0.gir This is Mutter's private fork of Clutter, deliberately installed outside the normal search paths. Only a small group of cooperating packages (basically Mutter and GNOME Shell) should be looking here. Those same packages need to set a special rpath or LD_LIBRARY_PATH to load the libraries. > > 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? Maybe? Whatever code the architecture-dependent definitions come from. For context, normally the GIR XML is produced by g-ir-scanner while building a GLib-based library (let's say GTK), by scanning its source code and maybe binaries. g-ir-scanner ignores anything wrapped in #ifndef __GI_SCANNER__, which is usually used for weird cpp constructs that confuse its somewhat simplistic C parser, but can also be used for things that aren't representable or useful in non-C languages. However, GLib is a special case - GObject-Introspection depends on GLib, so it would be annoyingly circular to have GLib build-depend on GObject-Introspection, and instead the GIR XML for GLib itself is built by the gobject-introspection source package (not the glib2.0 source package as it would usually be). I'm not sure precisely how that special case works. > > 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. Sure, but a package not being co-installable is a less serious bug, with a more difficult and more intrusive solution, than a package claiming to be co-installable but not achieving it. smcv