public inbox for gentoo-mips@lists.gentoo.org
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: "Michał Górny" <mgorny@gentoo.org>, gentoo-mips@lists.gentoo.org
Cc: mips@gentoo.org, multilib@gentoo.org
Subject: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs
Date: Sun, 29 Dec 2013 16:40:08 -0500	[thread overview]
Message-ID: <52C096B8.1020302@gentoo.org> (raw)
In-Reply-To: <20131228235839.5bb0305a@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

On 12/28/2013 5:58 PM, Michał Górny wrote:
> Hello, folks.
> 
> I've noticed today that mips uses the same CHOST value for all three
> ABIs it supports:
> 
> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
> 
> Long story short, this sucks and will cause trouble.
> 
> In the multilib stuff, we're using CHOST for two purposes:
> 
> 1. wrapped headers are put in /usr/include/$CHOST,
> 
> 2. multilib executables are prefixed with $CHOST-.
> 
> (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.
> 
> And those are just the examples I can think of. I suspect that more stuff
> may actually expect CHOST to uniquely identify build, especially some
> tricky hidden features in autotools :).
> 
> I'd suggest that you changed the CHOST values to uniquely identify ABI
> in use, at least in multilib profiles and preferably in all of them.

Matt can probably vouch for this better, but the only two ABIs affected by
this are n32 and n64.  mips[el]-unknown-linux-gnu implies a 32-bit
big/little endian CHOST, which means the o32 ABI.
mips64[el]-unknown-linux-gnu means either n32 or n64.  So no change should
be needed for o32-based installs.

According to this Debian wiki entry:
https://wiki.debian.org/Multiarch/Tuples

We would have to adopt mips64[el]-unknown-linux-gnuabin32 for n32 and
-gnuabin64 for n64.  Testing would be needed to watch for packages that
don't have updated config.sub/config.guess files and fail to recognize this
particular CHOST.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

  parent reply	other threads:[~2013-12-29 21:40 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 ` Joshua Kinard [this message]
2013-12-29 21:48   ` [gentoo-mips] " 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
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=52C096B8.1020302@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=gentoo-mips@lists.gentoo.org \
    --cc=mgorny@gentoo.org \
    --cc=mips@gentoo.org \
    --cc=multilib@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