________________________________
寄件者: jesse stone <[email protected]>
寄件日期: 2026年9月12日 下午 09:05
收件者: [email protected] <[email protected]>
主旨: Subject: [DISCUSSION] Cross-compilation failure in Mesa 26.2.x: Meson scope
leakage during Rust bindgen codegen
Hi Mesa developers,
I would like to highlight an architectural boundary issue during single-pass
cross-compilation in Mesa 26.2.x, specifically involving Meson and Rust bindgen
code generation (e.g., vtn_bindgen2).
1. Issue Summary:
When cross-compiling Mesa (e.g., x86_64 build machine targeting aarch64 host),
the Meson build fails at `src/compiler/spirv/meson.build` with:
ERROR: Tried to mix a host machine library ("vtn") with a build machine target
"vtn_bindgen2".
2. Root Cause & Context:
This occurs because host sysroot flags and libraries leak into the
build-machine execution context during Rust/bindgen processing. While GNU
Autotools strictly separated CC/CC_FOR_BUILD and Build/Host/Target triplets,
Meson's simplified dual-machine model easily leads to target sysroot leakage
when host-executed generators (like vtn_bindgen2) need to parse headers or link
against host libs.
A related packaging discussion and analysis can be found here:
https://github.com/termux/termux-packages/issues/31031
3. Proposal:
Could we strengthen the isolation in meson.build for codegen targets (e.g.
strict native: true separation and environment overrides) so distro maintainers
don't have to resort to manual two-pass builds?
Thanks,
Jesse Stone
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The GCC naming prefix is target
For native builds, some of the installed programs are also
installed with the target alias in front of their name
https://gcc.gnu.org/install/configure.html
Original definition of correct logic
1.
https://sensperiodit.files.wordpress.com/2011/04/hagen-the-definitive-guide-to-gcc-2e-apress-2006.pdf
CHAPTER 11 COMPILING GCC P.233
The build system is the machine on which you build GCC;
the host system is the machine on which the completed compiler will run;
and the target system is the machine for which the compiler will generate code.
To build GCC for a Microsoft Windows based Intel x86 system, you could use a
cross-compiler executing on a SPARC system running Solaris that know how to
create a binary that run on a W-intel system
The logic completely corresponds to the second statement:
To execute sparc-solaris-gcc in Sparc and generate gcc name x86-windows-gcc,
build is sparc.
x86-windows-gcc run in intel x86 and generate tvprogram,
host is intel x86.
tvprogram run in intel x86
target is intel x86.
2.
https://stackoverflow.com/questions/47010422/cross-compilation-terminologies-build-host-and-target
I have a PowerPC machine making a compiler that you will run
on an x86 machine that will This creates binaries that run on an ARM
architecture.
That makes the PPC the build, the x86 the host, and the target the ARM.
The logic completely corresponds to the second statement:
To execute powerpc-linux-gcc in powerpc and generate gcc name arm64-linux-gcc,
build is powerpc.
arm64-linux-gcc run in intel x86 and generate tvprogram,
host is intel x86.
tvprogram run in arm64,
target is arm64.
3.
https://blog.csdn.net/liufuchun111/article/details/81509651
(google translate to english)
./configure --build=i386-linux --host=powerpc-linux --target=powerpc-linux
This uses the i386-linux (--build) compiler to compile gcc.
The compiled gcc runs on powerpc-linux (--host).
This gcc is used to compile code that can run on powerpc-linux (--target).
The logic completely corresponds to the third statement:
To execute i386-linux-gcc in i386 and generate gcc name powerpc-linux-gcc,
build is i386.
powerpc-linux-gcc run in powerpc and generate tvprogram,
host is powerpc
tvprogram run in powerpc,
target is powerpc.
