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:

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

Links and references

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