Re: Meson build leaks host 'sh' path to target build when cross-compiled
- From
- Peter Seiderer <ps.report@gmx.net>
- Date
- Feb 10, 2025, 16:43 UTC
- Message-ID
- <20250210174335.6d6d2af2@gmx.net>
- In-Reply-To
- <xmqqlduddb8b.fsf@gitster.g>
Hello Junio,
On Mon, 10 Feb 2025 08:18:44 -0800, Junio C Hamano <gitster@pobox.com> wrote:
Show 46 quoted lines
> Patrick Steinhardt <ps@pks.im> writes:
>
> > On Sun, Feb 09, 2025 at 01:30:27PM +0100, Peter Seiderer wrote:
> > [snip]
> >> The meson build tries to execute the non-existent '/usr/bin/sh' (instead of
> >> '/bin/sh' as the autoconf build), 'which sh' on the host returns
> >> '/usr/bin/sh'...
> >>
> >> From meson.build
> >>
> >> [...]
> >> 186 shell = find_program('sh', dirs: program_path)
> >> [...]
> >> 685 '-DSHELL_PATH="' + fs.as_posix(shell.full_path()) + '"',
> >>
> >> Do not use the result of 'find_program('sh',...)' for '-DSHELL_PATH='
> >> (at least not for cross-compile), use fix '/bin/sh' instead or make it
> >> configurable via a meson option?
> >
> > Hm, very true. We're mixing up concerns here by treating the build
> > environment and the target environment the same.
> > ...
> > The patch should look somewhat like the attached patch, but it conflicts
> > with my in-flight patch series at [1]. I'll wait for that series to be
> > merged to `next` before sending out the fix.
>
> Interesting. When we did our make-based build, we never seriously
> considered cross building into a platform where the path to the
> basic tools differed between the host and target hosts. At least in
> our build procedure in olden times, I think we used to assume that
> what we just built can be run inside the build procedure on the host
> platform even outside the tests, which would make cross building
> impossible.
>
> Now, since we are "fixing" this aspect of the build for meson-based
> build, should we also make the same fix for make-based build as well?
>
> I'd have to say that I prefer to see it done out of pure principle
> (i.e. we earlier declared that meson is not yet replacing make, so
> adding new shinies only to meson-world is like making the make-world
> bitrot as if we do not care).
>
> But on the other hand, nobody complained that they cannot cross
> build with make-based build seriously enough to cause us consider
> doing something about it for the past 20 years, so the pragmast in
> me tells me that it is not worth it doing it in make-based build.Maybe all doing (autoconf) cross builds where happy with the defaults from the Makefile (SHELL_PATH = /bin/sh, PERL_PATH = /usr/bin/perl) on host and target (as the buildroot autoconf package since 2013) and only users doing native builds fiddled around with non-default values?
Regards, Peter
> > > Thanks for your report! > > Yup, thanks.