git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Meson build leaks host 'sh' path to target build when cross-compiled

From
PSPeter 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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 7 of 9 in “Meson build leaks host 'sh' path to target build when cross-compiled”
  1. Peter SeidererFeb 9, 2025
  2. Patrick SteinhardtFeb 10, 2025
  3. Peter SeidererFeb 10, 2025
  4. Patrick SteinhardtFeb 18, 2025
  5. Eli SchwartzFeb 18, 2025
  6. Junio C HamanoFeb 10, 2025
  7. Peter SeidererFeb 10, 2025
  8. Junio C HamanoFeb 10, 2025
  9. Peter SeidererFeb 11, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.