On Mon, 12 May 2025 at 07:52:53 +0200, Helmut Grohne wrote:
It ended up calling the cross wrapper. Unfortunately,
there is a short cut "if sysconfig.get_config_var('MULTIARCH') ==
DEB_HOST_MULTIARCH". The left hand gets influenced by setting
_PYTHON_SYSCONFIGDATA_NAME and therefore the short cut is taken
disabling qemu.
And what was the result? Failing to run the scanner because it was a
host-architecture executable and you don't have transparent qemu
emulation of the host architecture on the build architecture?
I was hoping that sysconfig.get_config_var('MULTIARCH') would return the
hard-coded architecture of the running Python interpreter, which would
have meant that this shortcut was correct. But if your override for
cross-building makes sysconfig describe the host architecture rather
than the build architecture, then yes this is wrong.
Is there anything - perhaps in sys or platform rather than sysconfig -
that would tell us, specifically, the architecture of the running Python
interpreter? Unfortunately I don't see anything immediately useful in
the documentation of those modules.
The sysconfig API documentation says "The sysconfig module provides
access to Python’s configuration information like the list of
installation paths and the configuration variables relevant for the
current platform" which unfortunately doesn't really help us to decide
whether it refers to the host or build platform: either one of those
could reasonably be described as "current".
I think g-ir-scanner is probably slow enough that an exec of the CAN_RUN
helper before we run the actual scanner is not a significant slowdown,
so I think dropping this shortcut would probably be OK. Please could you
propose a tested merge request or patch?
Are you targeting this for a trixie freeze exception, or for forky?
smcv
