Project:Toolchain/use native symlinks

= Overview =

Packages should not normally use or rely on, and similar commands at build time. They should use user's preferred tools specified in, and similar variables.

If is unset then  build systems normally discover CHOST-prefixed tools like  via --host=${CHOST}. Or ebuilds/eclass implement equivalent mechanism via and friends.

To ease catching of ebuilds that hardcode, and similar a few toolchain packages provide mode. Disabling removes unprefixed tools from.

Currently and provide the mechanism.

Why would you use it?

 * multilib environments and cross-compiler environments can use tools like or  by accident and target wrong ABI as a result.  is especially tricky as preprocessor rarely fails. It just generates data for wrong target.
 * environments with non-standard tools like or even  have a better chance being applied consistently.

TODO: links to more details on discoverable tools and expand on cross-compilation use case.

The good news is that autoconf build systems already use only prefixed variant of tools as Gentoo always passes --build=/--host=/--target= options to ./configure.

Removing native symlinks
Currently the flags are masked as many packages including base system fail to build if native symlinks are not present. Ideally they all should be fixed.

You need to unforce flags first:

And then disable USE:

List of removed files
For sys-devel/gcc the list of disappeared files is:

For sys-devel/binutils the list of disappeared files is:

Example fixes
TODO: autotools examples, make-based examples, leaking/embedding '/lib/cpp' into other toolchains examples.

automake AR example
This one is simplest. Autoconf frequently generates $(AR) calls to build static libraries. If the project uses automake build system (the hint is presence of Makefile.am file), then fix is a one-liner:

Example fix in abyss project: https://github.com/bcgsc/abyss/pull/335

hardcoded tool example
Sometimes ./configure hardcodes binutils' or gcc's tool like strings or as as-is. The fix is usually 2 lines:

Here is the cairo's example fix:

Taken from.

Ideally such AC_CHECK_TOOL tool discovery should be applied to all binutils-provided binaries. That way switching from binutils to llvm tool suite can be done with a few envvironment tweaks.

CC_FOR_BUILD (AX_PROG_CC_FOR_BUILD) example
The symptom is early ./configure failure:

This is usually caused by AX_PROG_CC_FOR_BUILD macro. Ideally it should check for ${build}-gcc presence (like AC_PROG_CC does for --host=... case). But it does not and requires user to supply CC_FOR_BUILD environment.

The simplest fix is to set CC_FOR_BUILD in eclass/ebuild if it's not explicitly defined by user as:

{{CodeBox|lang="diff"|1= --- a/x11-libs/gtk+/gtk+-3.24.20.ebuild +++ b/x11-libs/gtk+/gtk+-3.24.20.ebuild @@ -5,7 +5,7 @@ EAPI=6 GNOME2_LA_PUNT="yes" GNOME2_EAUTORECONF="yes"

-inherit flag-o-matic gnome2 multilib virtualx multilib-minimal +inherit flag-o-matic gnome2 multilib virtualx multilib-minimal toolchain-funcs

DESCRIPTION="Gimp ToolKit +" HOMEPAGE="https://www.gtk.org/" @@ -131,6 +131,8 @@ src_prepare { eapply "${FILESDIR}"/${PN}-3.22.20-libcloudproviders-automagic.patch

gnome2_src_prepare + +	export CC_FOR_BUILD="$(tc-getBUILD_CC)" }

multilib_src_configure { }}

Taken from.

Discussion/report on autoconf-archives: https://lists.gnu.org/archive/html/autoconf-archive-maintainers/2020-06/msg00000.html

Links and references

 * : tracker with known to fail ebuilds
 * : bug to user helpers to add to users' path