1 |
On Sunday 29 December 2013 17:04:34 Michał Górny wrote: |
2 |
> Dnia 2013-12-29, o godz. 16:52:05 "Anthony G. Basile" napisał(a): |
3 |
> > On 12/29/2013 04:48 PM, Markos Chandras wrote: |
4 |
> > > Yes all 3 ABIs use the same tuple. |
5 |
> > |
6 |
> > I think people are missing Mike's point from earlier, which is that |
7 |
> > tuples label toolchains and a toolchain can support multiple abis. So |
8 |
> > for example, what would one do on a system which simultaneously has o32, |
9 |
> > n32 and n64? -gnuabi32n32n64 looks pretty crazy. |
10 |
> |
11 |
> I'd say that we shouldn't limit the concept of 'toolchain' to |
12 |
> specifically GNU binutils + GNU gcc. Configure scripts can require much |
13 |
> more tools (like assemblers, *-config tools including pkg-config) |
14 |
> and I doubt we should really assume they all have some magic support |
15 |
> for ABI switching we had taken care of. |
16 |
|
17 |
the problem you pointed out is a limitation in our code: we cannot assume |
18 |
CHOST is unique for an ABI, thus using that as a unique path in generating ABI |
19 |
headers is wrong. conflating that bug in our code with any other issue is |
20 |
wrong. you can easily use ${CHOST}/${ABI} or ${CHOST}-${ABI} or just ${ABI} |
21 |
(since /usr/include is already associated with ${CHOST}). |
22 |
|
23 |
when it comes to *-config tools, those are known to be old and crap (for many |
24 |
more reasons than just multilib/cross-compiling). convert to .pc files and use |
25 |
pkg-config instead. |
26 |
|
27 |
> That said, it would be actually more reasonable to have three separate |
28 |
> triples for those ABIs, and link them to the same application if it |
29 |
> supports all three ABIs. Of course, we would need to ensure that |
30 |
> the application actually respects the triple via which it was called. |
31 |
|
32 |
creating a unique tuple is feasible via the vendor field as a last resort. |
33 |
however, unless you have a compelling reason to do so, i don't think it makes |
34 |
sense to pursue it. other than the vendor field, we are limited by what |
35 |
upstream GNU does and in that regard, they haven't always used unique tuples |
36 |
for ABI selection (this isn't limited to MIPS either). |
37 |
|
38 |
so to turn your base argument around, we shouldn't be limiting Gentoo to only |
39 |
support CHOSTs that also select ABIs uniquely. |
40 |
-mike |