Dnia 2013-12-29, o godz. 13:21:21
Mike Frysinger <vapier@gentoo.org> napisał(a):

> 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.

Out of curiosity, does a dedicated i686 toolchain on a multilib amd64
host have any benefits over the toolchain's -m32 options? Well, except
for not needing the explicit options.


> > > > (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.

'Should' is far away from reality. I'd rather avoid Gentoo inventing
pkg-config files for random packages where upstream simply refuses to
do that.

Then, there's LLVM. Their llvm-config has some more options than
pkg-config does, and it supports selecting single components. If we're
to do something semi-equal to that, we'd end up with 116 pkg-config
files, plus around 23 for clang. And each new supported target
increases that number by 5-7 files.

Of course, we could put them all in a single file.. but then we're
replacing one crap with another. And forcing the --as-needed hack
on top of it.

-- 
Best regards,
Michał Górny