On Mon, 15 Jan 2024 at 14:32:44 +0100, Helmut Grohne wrote:
> On Mon, Jan 15, 2024 at 12:38:54PM +0000, Simon McVittie wrote:
> > in general the
> > host g-ir-scanner will not even be executable during a cross-build
>
> I question this. g-ir-scanner is written in Python and it is fairly
> unlikely that /usr/bin/python3 will end up being the host Python that
> cannot be run. Hence using the g-ir-scanner from the host typically
> should work (or not) the same way as the one from the build
If it was pure Python, then this would be
true, but it loads a private module written in C
(/usr/lib/*/gobject-introspection/giscanner/_giscanner.cpython-311-*.so)
and that module needs to match the architecture of the python3
interpreter.
The result is that g-ir-scanner has two orthogonal architecture
dependencies:
1. It needs to be loading a _giscanner module whose
architecture matches python3: in practice this means adding
/usr/lib/${DEB_BUILD_MULTIARCH}/gobject-introspection to sys.path
2. Meanwhile it also needs to be using a $CC, $PKG_CONFIG, and search
paths that are appropriate for ${DEB_HOST_MULTIARCH}, and eventually
run a temporary host-architecture dumper binary, possibly via qemu
This makes it "the same shape" as gcc or ld, which are build-architecture
executables that have host-architecture object code as their
input/output. Unlike gcc, there is no built-in upstream way to build
a cross-g-ir-scanner analogous to a cross-compiler, and there does not
seem to be any interest in adding that upstream, which is why I had to
do this as a Debian-specific change.
However, reasoning similar to what's quoted above *does* work for tools
like gdbus-codegen, which *is* pure Python, avoiding the first of those
architecture dependencies. (As it happens, gdbus-codegen also operates
at the level of source code rather than binaries, so it avoids the second
architecture dependency too.)
smcv
