From: Mike Frysinger <vapier@gentoo.org>
To: gentoo-mips@lists.gentoo.org
Cc: "Michał Górny" <mgorny@gentoo.org>, basile@opensource.dyc.edu
Subject: Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs
Date: Sun, 29 Dec 2013 18:56:14 -0500 [thread overview]
Message-ID: <201312291856.15755.vapier@gentoo.org> (raw)
In-Reply-To: <20131229230434.7c033ed0@gentoo.org>
[-- 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 --]
next prev parent reply other threads:[~2013-12-29 23:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-28 22:58 [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs Michał Górny
2013-12-28 23:55 ` Markos Chandras
2013-12-29 2:12 ` Mike Frysinger
[not found] ` <20131229163354.35b65df5@gentoo.org>
2013-12-29 18:21 ` Mike Frysinger
2013-12-30 9:44 ` Michał Górny
2013-12-29 21:40 ` [gentoo-mips] " Joshua Kinard
2013-12-29 21:48 ` Markos Chandras
2013-12-29 21:48 ` Michał Górny
2013-12-29 21:48 ` Markos Chandras
2013-12-29 21:52 ` Anthony G. Basile
2013-12-29 22:04 ` Michał Górny
2013-12-29 23:56 ` Mike Frysinger [this message]
2013-12-30 7:51 ` Mike Frysinger
2013-12-30 8:17 ` sébastien bertoletto
2013-12-29 22:13 ` Markos Chandras
2013-12-29 22:19 ` Anthony G. Basile
2013-12-29 22:33 ` Markos Chandras
2013-12-29 23:47 ` Anthony G. Basile
2014-01-16 20:01 ` [gentoo-mips] " Michał Górny
2014-01-16 21:05 ` Anthony G. Basile
2014-01-16 21:24 ` Michał Górny
2014-01-16 22:29 ` Anthony G. Basile
2014-01-17 4:47 ` Michał Górny
2014-01-17 18:20 ` Markos Chandras
2014-01-17 18:36 ` Matt Turner
2014-01-17 19:38 ` Markos Chandras
2014-01-17 21:57 ` Matt Turner
2014-01-17 18:51 ` Michał Górny
2014-01-17 19:44 ` Markos Chandras
2014-01-21 20:52 ` Markos Chandras
2014-01-22 14:24 ` Anthony G. Basile
2014-01-22 14:38 ` Michał Górny
2014-01-22 20:39 ` Markos Chandras
2014-01-22 21:07 ` Anthony G. Basile
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201312291856.15755.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=basile@opensource.dyc.edu \
--cc=gentoo-mips@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox