Bug#1105149: g-ir-scanner cross wrapper does not interact well with cross building Python extensions

[Simon McVittie]

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