Re: Effectiveness of *_FOR_BUILD and *_FOR_TARGET environment variables

On 21/03/2026 18.23, Manuel Jacob wrote:
> Hi,
> 
> I found that the *_FOR_BUILD and *_FOR_TARGET environment variables are 
> not always used by the GCC build system.
> 
> If "${build}" = "${host}" ([1]), *_FOR_BUILD are not used and get 
> overwritten with a reference to the unsuffixed (“for host”) variable. I 
> think it would be useful to use the *_FOR_BUILD environment variables if 
> non-empty and default to the current behavior otherwise. My use case is 
> that, even in the native compilation case, I have a separate sysroot for 
> the libraries that the produced compiler links against. This requires 
> the build definition in my package manager to list all dependencies 
> explicitly instead of implicitly relying on libraries that happen to be 
> installed on the build system. The general goal is to handle native 
> compilation and cross-compilation as similar as possible.

It was pointed out to me in the IRC channel that having different 
sysroots for host can be called cross-compilation. So the description of 
my use case might have been misleading. To be more precise: My package 
manager always passes all tools for build, host and target explicitly. 
Even if "${build}" = "${host}", the host sysroot is separate and 
populated with packages that are binary-compatible with packages for 
build. This enforces clean separation of build and host dependencies in 
the package definition and ensures that "${build}" != "${host}" will 
usually just work. This was just for background information. I think it 
makes sense in general to preserve the environment variables if set, 
regardless of the values of $build and $host.

In the meantime, I sent a patch implementing the suggested behavior: 
https://gcc.gnu.org/pipermail/gcc-patches/2026-March/711459.html

> A separate issue is that, if $build != $host ([2], used by [3] and 
> following), the *_FOR_TARGET environment variables get overwritten with 
> the empty string and later overwritten with an inferred value. I think 
> it would be useful to keep the environment variable if non-empty. I’m 
> unsure what should take precedence if both a *_FOR_TARGET environment 
> variable and --with-build-time-tools is given. I tend towards that the 
> environment variable should take precedence because it’s more specific 
> (per-tool). But it should not make much difference in practice, as there 
> is no reason to pass contradicting values.

While implementing this, I found that for some environment variables 
(e.g. CC_FOR_TARGET), the suggested behavior (preserving the environment 
variable even if $build != $host, and taking precedence over 
--with-build-time-tools) was already implemented, so I followed that 
behavior in the patch: 
https://gcc.gnu.org/pipermail/gcc-patches/2026-March/711626.html

> Does that make sense? Or is there a good reason for keeping the current 
> behavior?
> 
> -Manuel
> 
> 
> [1] https://gcc.gnu.org/git/? 
> p=gcc.git;a=blob;f=configure.ac;h=c5de225b0ac3bfc7e4b3c0eea6c390509af58bd5;hb=HEAD#l1470
> [2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=config/ 
> acx.m4;h=7304d7b82adb2b81a8a14ede14abf3ac688063f8;hb=HEAD#l353
> [3] https://gcc.gnu.org/git/? 
> p=gcc.git;a=blob;f=configure.ac;h=c5de225b0ac3bfc7e4b3c0eea6c390509af58bd5;hb=HEAD#l4206