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
Patrick Steinhardt <ps@pks.im>
Date
Feb 18, 2025, 11:47 UTC
Message-ID
<Z7RzPkiBfbYPhKp_@pks.im>
In-Reply-To
<20250210122603.5130e309@gmx.net>
On Mon, Feb 10, 2025 at 12:26:03PM +0100, Peter Seiderer wrote:
Show 44 quoted lines
> On Mon, 10 Feb 2025 08:41:18 +0100, Patrick Steinhardt <ps@pks.im> wrote:
> > 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.
> >
> > I guess the proper fix is to wire up the "native:" parameter when we
> > call `find_program()`, which allows us to tell Meson whether it should
> > find an executable for the build or the target host. And then, for those
> > binaries where we actually need to know about both the build and target
> > host's locations, we'd end up calling `find_program()` twice.
> >
> > For executables that are supposed to be used on the target host Meson
> > would then know to first consult the cross file, which could look like
> > this:
> >
> >     [binaries]
> >     sh = '/target/path/to/sh'
> >     perl = '/target/path/to/perl'
> >
> > Meson would then pick up that file via `meson setup --cross-file
> > <CROSSFILE_PATH> <BUILDDIR>`.
> 
> Sorry, I believe this will not work..., the description of the native
> parameter in find_program ([2]) on the first sight sounds like doing the
> right thing, but as far as I read the 'Cross compilation' page ([3], [4]) the
> tools under the '[binaries]' section are the tools used while cross-compiling
> (running on the build machine) and not the paths/tools on the target
> (or as meson nomenclature host/target)...
Quoting the documentation of `find_program()`'s `native` parameter [1]:
    Defines how this executable should be searched. By default it is set to
    false, which causes Meson to first look for the executable in the cross
    file (when cross building) and if it is not defined there, then from the
    system. If set to true, the cross file is ignored and the program is
    only searched from the system.

So I think this should work as expected when passing the file via `--cross-file`, shouldn't it? If we are cross-compiling we'd find the target binaries via the cross file when `native: false`, which is exactly what we want.

But I see what you're saying. The _intent_ is to specify the environment of the cross-compiling environment, and not to describe the target environment.

I can think of two alternatives:
  - We can introduce build options for this. If unset, we continue to
    use the result of `find_program()`. Otherwise, we use the value
    specified by the user.
  - We can introduce properties into the cross file that allow the user
    to specify those parameters. We can then retrieve them by calling
    `meson.get_external_property()`, but only when cross-compiling.
Let me also Cc Eli, he might have an opinion on how to do this.
Show 13 quoted lines
> > diff --git a/templates/meson.build b/templates/meson.build
> > index 1faf9a44ce..986c2e03be 100644
> > --- a/templates/meson.build
> > +++ b/templates/meson.build
> > @@ -1,6 +1,6 @@
> >  template_config = configuration_data()
> > -template_config.set('PERL_PATH', perl.found() ? fs.as_posix(perl.full_path()) : '')
> > -template_config.set('SHELL_PATH', fs.as_posix(shell.full_path()))
> > +template_config.set('PERL_PATH', perl.found() ? fs.as_posix(target_perl.full_path()) : '')
> 
> Above should read (perl.found() vs. target_perl.found()):
> 
>    +template_config.set('PERL_PATH', target_perl.found() ? fs.as_posix(target_perl.full_path()) : '')
Ah, yes, indeed.
Patrick
[1]: https://mesonbuild.com/Reference-manual_functions.html#find_program
Previous: Peter SeidererNext: Eli Schwartz
Message 4 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.