Why does Meson not automatically find the strip binary when cross-building?

[uilianries]

Hello team!

First I would like to thank you all for providing such a nice build tool, which is getting ever more popular.

I’ve noticed a behavior in Meson that seems divergent from other build systems like CMake and Autotools. I know they are different projects and may have different proposals.

When cross-building a project, Meson does not automatically find the strip binary, even though it warns about strip not being found, like this:

WARNING: Cross file does not specify strip binary, result will not be stripped.

This requires explicitly specifying the strip binary in the cross file or via the environment STRIP=, which can be inconvenient.

In contrast, both CMake and Autotools automatically deduce and locate the appropriate strip binary for the target architecture during cross-compilation, because they use the triplet (compiler prefix) for it. This makes the process smoother and requires less manual configuration.

For instance, using CMake, I only set the compiler path and target architecture for my toolchain, like this:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)

set(CMAKE_C_COMPILER /opt/arm-gnu-toolchain-13/bin/aarch64-none-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER /opt/arm-gnu-toolchain-13/bin/aarch64-none-linux-gnu-g++)

set(CMAKE_FIND_ROOT_PATH /opt/arm-gnu-toolchain-13)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Then, I run the CMake setup as usual:

cmake -S . -B build/ -DCMAKE_TOOLCHAIN_FILE=aarch64-toolchain.cmake

-- The CXX compiler identification is GNU 13.3.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /opt/arm-gnu-toolchain-13/bin/aarch64-none-linux-gnu-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/cmake-cross/build

Now, checking my CMake cache file, it lists the strip executable automatically found as well:

grep strip build/CMakeCache.txt 
CMAKE_STRIP:FILEPATH=/opt/arm-gnu-toolchain-13/bin/aarch64-none-linux-gnu-strip

Of course, I can override the strip path as well, but that's not the case.

This issue may be related to #13755 as well.

---

Could you clarify why Meson diverges from this behavior?
Is it something that could be improved in future versions?

Thank you for your time and for this great project!

Cheers!

[eli-schwartz]

@jpakkane's original design goals for cross compiling included an intention to be very explicit (some might say, verbose) about the toolchain used. It's the same reason you explicitly specify the compiler in a cross file too.

Meson now has meson env2mfile that can automatically produce a cross file. I seem to recall that @smcv had a suggestion for making this better, though I cannot find a relevant feature request filed on the issue tracker...

[uilianries]

@eli-schwartz Thank you for the clarification and for answering my question!

I agree that being explicit is much safer than being implicit in most cases. It may cause more work for users, but at least, maintainers can be sure about the expected scenario.

Please, tell me if there is a plan for adding automatic strip executable detection at least, or if Meson is open for contributions via PRs. Best regards!

[smcv]

Meson now has meson env2mfile that can automatically produce a cross file. I seem to recall that smcv had a suggestion for making this better, though I cannot find a relevant feature request filed on the issue tracker...

It's possible that we discussed this on the Debian bug tracking system rather than upstream, and my suggestion might have been rejected by an upstream maintainer sufficiently forcefully that I didn't think it was worth spending the time to suggest it in the upstream issue tracker and get it rejected again.

At the moment, meson env2mfile correctly assumes that Debian prefers to use architecture-prefixed tools for cross architectures (${DEB_HOST_GNU_TYPE}-pkg-config, ${DEB_HOST_GNU_TYPE}-strip, etc.), but also assumes that non-Debian-derived systems never do this.

However, having cross-tools prefixed with a GNU architecture tuple is not Debian-specific: if anything it's more of a GNUism. Autotools systematically tries ${host}-foo before foo for many cross-relevant tools, where ${host} is the GNU tuple describing the host architecture, for example aarch64-linux-gnu for GNU/Linux on aarch64; and similarly, ad-hoc Makefile-based build systems like the one for the Linux kernel often use $(CROSS_COMPILE)foo, where $(CROSS_COMPILE) is empty by default but can be set to something like aarch64-linux-gnu- if cross-tools are desired. So I think it would make sense to make this common pattern easier, without requiring authors of cross-files to know the full list of cross-tools that Meson can be told to use.

One way to achieve that could be for meson env2mfile to have a mode where the input is a GNU tuple, and the output tries that prefix for many cross-tools, similar to how it uses ${DEB_HOST_GNU_TYPE} on Debian. (Perhaps meson env2mfile --cross --gnutuple=aarch64-linux-gnu, analogous to the current meson env2mfile --cross --debarch=arm64?)

Or, another way to achieve that could be for Meson itself to be aware of the prefixing convention.

[jpakkane]

but also assumes that non-Debian-derived systems never do this

It's not so much "assumes" but of "I do not know how other distros do this so do not guess but instead do the simple thing and wait for MRs from people who actually know how things should be".

So if there is a way to do something along the lines of "reliably detect that we are on distro X and do all the custom things needed by it in env2mfile automatically so that nobody ever has to do that again" then that is definitely something that should happen.

[eli-schwartz]

It's possible that we discussed this on the Debian bug tracking system rather than upstream, and my suggestion might have been rejected by an upstream maintainer sufficiently forcefully that I didn't think it was worth spending the time to suggest it in the upstream issue tracker and get it rejected again.

I think it happened in #debian-devel, where I am the only upstream maintainer. I said I found the idea intriguing and worth thinking about implementing. :)