The GNU Autotools terminology of build/host/target was originally created specifically for compiling GCC.
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. July 8, 1999 describes events that occurred in 1995.
http://www.kilmnj.com/g77/what.html
Around late 1995, I did a criss-cross build of g77, which entailed building a version of g77 on a Linux/Intel platform that ran on a DOS/Intel platform and generated code for an ecoff/i960 machine.
It was about a weeks' work, but some of the problems I ran into have been fixed since then in g77, gcc, and the cross-platform development tools provided (generously) by Cygnus Support. (Cygnus and others use the term Canadian Cross to mean what
I call criss-cross, that is, three-system, builds, where a compiler for machine C is built to run on B from machine A.)
2. The document was created on March, 17 2001
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_3.html
"3. Installing GNU CC"
The build machine is the system which you are using,
the host machine is the system where you want to run the resulting compiler,
and the target machine is the system for which you want the compiler to generate code.
3.
The GNU configure and build system 1998
https://www.mediafire.com/view/tk1v3pw53z17lpe/build_host_target_1998.jpg/file
page. 28
6.2 Canadian Cross Concepts
The system on which the tools are being built is called the build system.
The system on which the tools will run is called the host system.
An example of building a cross compiler using a Canadian Cross would be building a Windows cross MIPS ELF compiler on a GNU/Linux system. In this case the build system would be GNU/Linux, the host system would be Windows, and the target system would be MIPS ELF.
4.
The Definitive Guide to GCC Second Edition 2006
https://www.mediafire.com/view/6kl9xbzfz0a7erq/build_host_target_2006.jpg/file
Page. 233
CHAPTER 11 COMPILING GCC
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.
5.
https://stackoverflow.com/questions/47010422/cross-compilation-terminologies-build-host-and-targetI 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.
6.
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Confuse concept later, this was changed to:
https://gcc.gnu.org/onlinedocs/gccint.pdf
There are three system names that the build knows about:
the machine you are building on (build),
the machine that you are building for (host),
and the machine that GCC will produce code for (target).
When you configure GCC, you specify these with --build=, --host=, and --target=
https://mesonbuild.com/Cross-compilation.html
build machine: The computer performing the compilation.
host machine: The machine where the compiled binary runs.
target machine: The machine where the compiled binary's output runs.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
https://lists.openembedded.org/g/openembedded-core/topic/issues_with_meson_in_sdk_with/72348468
As explicitly documented in the:
"meson assumes that CC, CXX, CFLAGS, and other vars point to native tools. However, in an OE SDK, they point to cross-tools. Thus meson fails under the SDK because it tries to use the cross-tools for native tasks (I get the error "nm does not work" because meson tried to use the cross-nm for symbol extraction)."
This historic Yocto SDK issue highlights a fundamental architectural flaw in Meson that continues to plague cross-compiling environments today:
Broken Scope Isolation: Meson inherently conflates environment variables and target sysroots, assuming CC/CXX/CFLAGS belong strictly to native tools while implicitly polluting native execution contexts when a cross-file is provided.
Structural Fragility in Single-Pass Builds: When upstream projects like Mesa rely on host-executed codegen tools (e.g., bindgen, mesa-clc, or LLVM/libclang integrations), Meson's lack of strict taxonomy boundary allows target dynamic libraries and sysroot flags to bleed into native code generators.
The Result: Rather than clean build-system isolation, distro maintainers (Yocto, Termux, Debian) are forced into perpetual workarounds (e.g., two-pass builds, wrapper scripts, or manual LIBCLANG_PATH exports) whenever an upstream toolchain or codegen regression occurs.
While individual codegen regressions (like in rust-bindgen) can be patched, Mesa's cross-compilation pipeline will remain uniquely vulnerable as long as these underlying Meson semantics continue to pollute native toolchains during single-pass cross builds.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
School A - Classical / Proper-Noun School:
The "a mouse is a computer input device" logic. It strictly follows the GNU Autotools and GCC specifications.[1995][1998][2006]
Definition: In this specification, build / host / target are technical terms that specifically describe the production and operation relationship of the Toolchain.
Facts:
build = the place where the toolchain is built.
host = the environment where the toolchain runs, and is used to build the tvprogram.
Stance: Technical terms have a rigorous physical definition and historical context. You cannot arbitrarily guess or conflate them using the literal, everyday meaning of English.
School B - Vernacular / Verb-Literal School:
The "build is just the verb to build" logic. It forcibly interprets system terminology using everyday English verb grammar [Build = Make / Compile].
Definition: When they see the environment for building the tvprogram, their brain automatically translates it as:
Building tvprogram implies The machine that builds tvprogram implies Build Machine, ignoring that in Autotools, host is defined as "the environment that executes the compile action and produces the binary", they mistakenly think the machine whose CPU is currently spinning running gcc is called build.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GNU Original Definition = Past -> Present -> Future
Past (build): The existing old compiler, like sparc-solaris-gcc, which existed in the past and was used to compile the new GCC.
Present (host): The new compiler you just built, like x86-windows-gcc, which is currently running on the host.
Future (target): The TV program that this new compiler will generate in the future, which will run on the target.
Three points in time, one compilation chain.
Meson = Present -> Future, no past
Present (build_machine): Where you are currently building by pressing enter.
Future (host_machine): Where your compiled code will run in the future.
The original purpose of the definition was to achieve cross-compile in one go.
Now, the definition is polluted, Mesa requiring a build for x64 first, followed by a build for arm64.
沒有留言:
張貼留言