Re: Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gobject-introspection/issues/323
On Wed, 20 Feb 2019 at 17:03:43 +0100, Helmut Grohne wrote:
> On Sat, Feb 16, 2019 at 05:02:53PM +0000, 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.
>
> This is not specific to Debian. It is an upstream problem. The files are
> supposed to be architecture-independent, but factually are not.
I've started a conversation upstream: see link above.
libgirepository1.0-dev is not, practically, multiarch co-installable
anyway (because it depends on the gobject-introspection toolset, which is
architecture-dependent and I don't think it would be correct to make it
Multi-Arch: foreign), so for now my inclination is to revert the addition
of Multi-Arch: same to libgirepository1.0-dev. As far as I can see this
would not break anything that is not already broken.
> > My understanding is that GIR is intended to be a collection of
> > machine-readable facts about the source code [...] However, those facts
> > are partially derived from inspecting the binary
>
> Deriving from the binary practically happens by
> loading it into some tool. I don't remember the details here, but this
> where things break down: The purpose of these GIR files is software
> development. Why would you install them for multiple architectures?
> Only if you are cross compiling something. But then you load libraries
> into some tool, you're faced with an Exec format error. This doesn't
> work at all regardless of whether fix the M-A annotations.
I think part of the purpose of the GIR XML and the binary typelibs
is precisely that you can read it to get facts about the API (and,
indirectly, ABI) of a library *without* having to dlopen and inspect
the library and its source code yourself, for example to generate Vala
language bindings for it.
In principle, they ought to be useful when cross-compiling: you can read
Foo-1.0.gir and the riscv64 version of Foo-1.0.typelib, and use them to
generate code that will run on riscv64. As long as you don't execute
that code immediately yourself, you don't actually need to be able to
run riscv64 code.
I agree that *gathering* that information requires the ability
to dlopen the library that you're inspecting; and, yes, that
breaks the ability to do "true" cross-compilation (by which I mean
compiling for a host architecture whose code you cannot execute,
not even with qemu-user-binfmt) of libraries that include their own
GObject-Introspection information.
> You may ask: How do other distributions solve this? Well, ptxdist and
> yocto use qemu for gobject-introspection.
I think having library development files coexist for multiple
architectures is valuable even if you need to execute host-architecture
code to consume them: only being able to cross-compile to architectures
whose code you can execute is not as good as being able to do "true"
cross-compilation, but it's also better than not being able to
cross-compile at all.
In particular, multiarch co-installation for amd64 + i386 on an amd64
system is a really useful thing to be able to do.
smcv
Reply to: