Bug#1061250: gjs FTCBFS: cxx.run always fails cross compilation

[Helmut Grohne]

Hi Simon,

On Sun, Jan 21, 2024 at 03:50:17PM +0000, Simon McVittie wrote:
> On Sun, 21 Jan 2024 at 12:56:49 +0100, Helmut Grohne wrote:
> > +if meson.is_cross_build()
> 
> In my experience, this function call is usually the wrong tool:
> I think it would likely be more in line with what upstream wants if
> it was based on "if not meson.can_run_host_binaries()", so that if we
> happen to be able to run host binaries (via i386-on-amd64, binfmt_misc
> or an explicitly configured EXE wrapper), the check will still be done.

Thank you for pointing at meson.can_run_host_binaries(). I concur that
this is what we want here. I shall remember this for future patches.

I concur that is_cross_build rarely is what we want and in numerous
places, I have proposed discarding such checks. In this case, the check
was already there and I have merely shifted it around subtly changing
the semantics such that it won't attempt to do the sanity check during
cross compilation.

> Does cxx.run() work as though we were doing a native build if Meson is
> run with a cross-file that configures an EXE wrapper, similar to
> <https://salsa.debian.org/gnome-team/glib/-/commit/df446722f51b9c35b6278a38b10784ba9dd3c919>?
> I hope that it will.

That would also be my expectation.

> gjs is neither installable nor useful without GObject-Introspection, so
> on any architecture where we would consider cross-compiling gjs, we almost
> certainly already have qemu-user available.

Whils this is true in principle, the way you have integrated qemu into
gir, this fact is not exposed to the build system. Just because
g-ir-scanner uses qemu, does not imply that a crossfile has set this up
(while it still probably would be useful to set this up).

> > +    warning('''This is a cross build. A check that a minimal
> > +SpiderMonkey program executes will not be performed. Before shipping GJS, you
> > +should check that it does not crash on startup, since building SpiderMonkey with
> > +the wrong configuration may cause that.''' + recommended_configuration)
> 
> This might still be a good idea even if an EXE wrapper is enough to
> resolve the build failure, but I'd prefer to take this sort of thing
> upstream rather than applying it unilaterally.

Yes, the bug is tagged upstream and resolving it upstream is what I
preferred - even if it takes longer that way.

Do you think this needs further improvement beyond replacing
is_cross_build with can_run_host_binaries?

Helmut