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

[Helmut Grohne]

Hi Simon,

thanks for your quick followup.

On Mon, May 12, 2025 at 01:01:05PM +0100, Simon McVittie wrote:
> 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?

You correctly completed what I left implicit.

> 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.

The sysconfig module is extensively used while cross building Python
extension modules. Therefore, it describes the host architecture in
common build scenarios indeed.

> 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.

I concur. In an interpreter with _PYTHON_SYSCONFIGDATA_NAME set, both
sys and platform describe the build architecture, but the interfaces
they provide are not exactly useful in telling the build architecture.

> 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?

The Python interpreter startup we incur via cross-g-ir-tool should be
larger than CAN_RUN already. I concur that dropping the short-cut should
fix the issue at hand. I've copied d-cross at l.d.o to acquire some more
ideas before moving forward with that approach.

> Are you targeting this for a trixie freeze exception, or for forky?

The proposed change bears a bit of risk as it may influence native
builds. It also affects a small minority of packages. I suggest
deferring this to forky.

Helmut