1 |
On Sunday 29 December 2013 10:33:54 Alexis Ballier wrote: |
2 |
> On Sat, 28 Dec 2013 21:12:53 -0500 Mike Frysinger wrote: |
3 |
> > you cannot assume CHOST uniqueness. |
4 |
> |
5 |
> why ? I was under the impression that a CHOST entirely defines an ABI |
6 |
|
7 |
that has never been the case. a CHOST defines a unique toolchain, not a unique |
8 |
ABI. a toolchain may support more than one ABI (and frequently does). |
9 |
|
10 |
we've run into issues in the past where people install a toolchain via |
11 |
crossdev that uses the same tuple as the non-default ABI one (e.g. people on |
12 |
an amd64 system do `crossdev i686-pc-linux-gnu`) and then the multilib code |
13 |
gets confused. but it's been much more of a hassle to try and get configure |
14 |
scripts to use compile tests rather than probe the CHOST, so we've just lived |
15 |
with this lesser evil. |
16 |
|
17 |
> > > (1) here is not really a killer feature but I'd rather avoid |
18 |
> > > changing this at this point. (2) is actually a killer feature, |
19 |
> > > since the eclass sets CHOST properly and thanks to that |
20 |
> > > AC_CHECK_TOOL and friends can find multilib *-config progs and |
21 |
> > > stuff without any special hackery. |
22 |
> > |
23 |
> > *-config progs are dead. use pkg-config. |
24 |
> |
25 |
> ok; but shouldnt we kill that tc-getPKG_CONFIG() which returns |
26 |
> $CHOST-pkg-config then ? |
27 |
|
28 |
i didn't mean specifically use `pkg-config`. packages should be using .pc files |
29 |
instead of *-config scripts. |
30 |
|
31 |
you're right that pkg-config is natively unaware of ABI, but the multilib |
32 |
eclasses workaround that by setting PKG_CONFIG vars to the right place. |
33 |
-mike |