The whole purpose of this function is really just to run specific
commands "as CHOST=${CBUILD}" during cross, in case you really need
CBUILD copies of stuff e.g. to do asset generation.We also have an econf helper which... sets CHOST then runs econf. And ebuilds such as anki and zig also override CHOST when using tc-env_build, which implies it is useful/needed. While exploring app-containers/containerd failing to cross build, I observed a challenging issue for go-env.eclass as well. One may wish to use tc-env_build to override the go env to set up, as such: ``` tc-env_build go-env_set_compile_environment emake .... ``` but the latter function sets go's host mode (goarch) based on CHOST, while the former function checks for cross mode by comparing CHOST versus CBUILD. Once again, we need a wrapper for tc-env_build to run, just to set CHOST? It seems simpler and more consistent to always set it. Bug: https://bugs.gentoo.org/966257 Signed-off-by: Eli Schwartz <[email protected]> --- This seems logical to me, but I really need someone who actually uses cross to review it. eclass/toolchain-funcs.eclass | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass index 3f820c2d8559..9772e3f25e7a 100644 --- a/eclass/toolchain-funcs.eclass +++ b/eclass/toolchain-funcs.eclass @@ -1,4 +1,4 @@ -# Copyright 2002-2025 Gentoo Authors +# Copyright 2002-2026 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: toolchain-funcs.eclass @@ -388,6 +388,7 @@ tc-export_build_env() { # the target build system does not check. tc-env_build() { tc-export_build_env + CHOST=${CBUILD:-${CHOST}} \ CFLAGS=${BUILD_CFLAGS} \ CXXFLAGS=${BUILD_CXXFLAGS} \ CPPFLAGS=${BUILD_CPPFLAGS} \ @@ -445,8 +446,7 @@ tc-env_build() { # @CODE econf_build() { local CBUILD=${CBUILD:-${CHOST}} - econf_env() { CHOST=${CBUILD} econf "$@"; } - tc-env_build econf_env "$@" + tc-env_build econf "$@" } # @FUNCTION: tc-ld-is-bfd -- 2.52.0
