On Sunday 29 December 2013 10:33:54 Alexis Ballier wrote:
> On Sat, 28 Dec 2013 21:12:53 -0500 Mike Frysinger wrote:
> > you cannot assume CHOST uniqueness.
> 
> why ? I was under the impression that a CHOST entirely defines an ABI

that has never been the case.  a CHOST defines a unique toolchain, not a unique 
ABI.  a toolchain may support more than one ABI (and frequently does).

we've run into issues in the past where people install a toolchain via 
crossdev that uses the same tuple as the non-default ABI one (e.g. people on 
an amd64 system do `crossdev i686-pc-linux-gnu`) and then the multilib code 
gets confused.  but it's been much more of a hassle to try and get configure 
scripts to use compile tests rather than probe the CHOST, so we've just lived 
with this lesser evil.

> > > (1) here is not really a killer feature but I'd rather avoid
> > > changing this at this point. (2) is actually a killer feature,
> > > since the eclass sets CHOST properly and thanks to that
> > > AC_CHECK_TOOL and friends can find multilib *-config progs and
> > > stuff without any special hackery.
> > 
> > *-config progs are dead.  use pkg-config.
> 
> ok; but shouldnt we kill that tc-getPKG_CONFIG() which returns
> $CHOST-pkg-config then ?

i didn't mean specifically use `pkg-config`.  packages should be using .pc files 
instead of *-config scripts.

you're right that pkg-config is natively unaware of ABI, but the multilib 
eclasses workaround that by setting PKG_CONFIG vars to the right place.
-mike