public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs
  @ 2013-12-29 23:56 99%     ` Mike Frysinger
  0 siblings, 0 replies; 1+ results
From: Mike Frysinger @ 2013-12-29 23:56 UTC (permalink / raw
  To: gentoo-mips; +Cc: Michał Górny, basile

[-- Attachment #1: Type: Text/Plain, Size: 2193 bytes --]

On Sunday 29 December 2013 17:04:34 Michał Górny wrote:
> Dnia 2013-12-29, o godz. 16:52:05 "Anthony G. Basile" napisał(a):
> > On 12/29/2013 04:48 PM, Markos Chandras wrote:
> > > Yes all 3 ABIs use the same tuple.
> > 
> > I think people are missing Mike's point from earlier, which is that
> > tuples label toolchains and a toolchain can support multiple abis.  So
> > for example, what would one do on a system which simultaneously has o32,
> > n32 and n64?  -gnuabi32n32n64 looks pretty crazy.
> 
> I'd say that we shouldn't limit the concept of 'toolchain' to
> specifically GNU binutils + GNU gcc. Configure scripts can require much
> more tools (like assemblers, *-config tools including pkg-config)
> and I doubt we should really assume they all have some magic support
> for ABI switching we had taken care of.

the problem you pointed out is a limitation in our code: we cannot assume 
CHOST is unique for an ABI, thus using that as a unique path in generating ABI 
headers is wrong.  conflating that bug in our code with any other issue is 
wrong.  you can easily use ${CHOST}/${ABI} or ${CHOST}-${ABI} or just ${ABI} 
(since /usr/include is already associated with ${CHOST}).

when it comes to *-config tools, those are known to be old and crap (for many 
more reasons than just multilib/cross-compiling).  convert to .pc files and use 
pkg-config instead.

> That said, it would be actually more reasonable to have three separate
> triples for those ABIs, and link them to the same application if it
> supports all three ABIs. Of course, we would need to ensure that
> the application actually respects the triple via which it was called.

creating a unique tuple is feasible via the vendor field as a last resort.  
however, unless you have a compelling reason to do so, i don't think it makes 
sense to pursue it.  other than the vendor field, we are limited by what 
upstream GNU does and in that regard, they haven't always used unique tuples 
for ABI selection (this isn't limited to MIPS either).

so to turn your base argument around, we shouldn't be limiting Gentoo to only 
support CHOSTs that also select ABIs uniquely.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-12-28 22:58     [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs Michał Górny
2013-12-29 21:52     ` [gentoo-mips] " Anthony G. Basile
2013-12-29 22:04       ` Michał Górny
2013-12-29 23:56 99%     ` Mike Frysinger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox