From: Matthias Klose <doko@ubuntu.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Matthias Klose <doko@ubuntu.com>,
GCC Patches <gcc-patches@gcc.gnu.org>,
Steve Langasek <vorlon@debian.org>
Subject: Re: [patch] support for multiarch systems
Date: Sun, 21 Aug 2011 07:55:00 -0000 [thread overview]
Message-ID: <4E504D21.7090709@ubuntu.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1108202020470.28732@digraph.polyomino.org.uk>
On 08/20/2011 10:39 PM, Joseph S. Myers wrote:
> On Sat, 20 Aug 2011, Matthias Klose wrote:
>
>> The multiarch triplets are defined in the target specific tmake files, and
>> provided for all known existing multiarch implementations (currently Debian,
>> Ubuntu and derivatives). For non-multilib'd configurations, the triplet is
>
> Is there a specification somewhere of what the various triplets mean?
there is
https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-February/006674.html
http://wiki.debian.org/Multiarch/Tuples
but the documentation is not up to date. The tuples in use are:
$ for a in alpha amd64 armel armhf hppa i386 ia64 mips mipsel powerpc powerpcspe
ppc64 s390 s390x sh4 sparc sparc64 kfreebsd-i386 kfreebsd-amd64 hurd-i386; do
dpkg-architecture -a$a -qDEB_HOST_MULTIARCH 2>/dev/null; done
alpha-linux-gnu
x86_64-linux-gnu
arm-linux-gnueabi
arm-linux-gnueabihf
hppa-linux-gnu
i386-linux-gnu
ia64-linux-gnu
mips-linux-gnu
mipsel-linux-gnu
powerpc-linux-gnu
powerpc-linux-gnuspe
powerpc64-linux-gnu
s390-linux-gnu
s390x-linux-gnu
sh4-linux-gnu
sparc-linux-gnu
sparc64-linux-gnu
i386-kfreebsd-gnu
x86_64-kfreebsd-gnu
i386-gnu
>> defined in MULTIARCH_DIRNAME, for multilib'd configurations each directory in
>> MULTILIB_OSDIRNAMES gets an multiarch directory associated, separated by a colon
>
> I don't see any documentation in fragments.texi for this
> (MULTIARCH_DIRNAME is new so certainly needs documenting, even if you get
> away with not adding to the nonexistent documentation for
> MULTILIB_OSDIRNAMES (PR 25508)).
well, I hope I get away with copying it from genmultilib without closing the
report ;)
>> (e.g. ../lib:x86_64-linux-gnu). The multiarch names are as used by Debian, the
>
> Does this work with the "gccdir=osdir" and "gccdir=!osdir" cases before
> the colon?
amd64 is configured this way, and I don't handle the !osdir case other than for
the multilib osdir.
>> mips names go back to a discussion from 2006 [3] to match thee, ones for glibc.
>
> For x86, shouldn't a name be allocated for x32?
maybe, but I didn't see a port yet.
> For m68k, classic m68k and ColdFire have incompatible ABIs. So you need
> to define what m68k-linux-gnu means of the two ABIs. Unfortunately
> building for ColdFire has been broken for some time, since
> <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01845.html> (this ought to
> have been dependent on the --with-arch configurey).
it's the classic m68k. yes, it has to be defined.
> For 32-bit Power, hard-float and soft-float ABIs are incompatible.
> Furthermore, the soft-float ABI is used at function-calling level for
> e500v1 and e500v2 - but there are differences in the details of the glibc
> symbols exported (and at least the fenv.h ABI is incompatible between
> soft-float and e500). So actually there are four variants at the glibc
> level. You need to define what powerpc-linux-gnu means and avoid it being
> used for anything incompatible.
same here. powerpc-linux-gnu is the hard-float one. Debian has an e500 port in
development which currently uses powerpc-linux-gnuspe
> For MIPS, the hard-float and soft-float ABIs are incompatible. So you
> need twelve triplets, not six.
yes. but I didn't see a soft-float mips port yet.
> For ARM, you have a ChangeLog entry with no corresponding patch. You need
> to distinguish big and little endian; old ABI, EABI soft-float ABI and
> EABI hard-float ABI (six triplets).
ok, added. Debian has little endian ports only. I see that dpkg treats the
obsolete armeb port as armeb-linux-gnu.
> Not all of those variants necessarily are configurable in a multilib
> configuration in the FSF tree (the e500 variants can be achieved with
> powerpc-linux-gnuspe triplets, for example, but those don't have other
> multilibs). So maybe some of the names won't actually appear in the FSF
> sources - but you still need to define the semantics of the names that do
> appear (whether in the manuals, on the GCC wiki or elsewhere) and
> preferably have somewhere to define semantics for the names not used in
> multilib configurations in FSF GCC.
For now, the multiarch documentation should be consolidated; I would like to add
a link from the FCC wiki to this documentation mentioned above.
Matthias
next prev parent reply other threads:[~2011-08-21 0:11 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-20 21:07 Matthias Klose
2011-08-20 21:16 ` Jakub Jelinek
2011-08-21 2:22 ` Matthias Klose
2011-08-20 21:44 ` Joseph S. Myers
2011-08-21 7:55 ` Matthias Klose [this message]
2011-08-21 10:20 ` Andrew Pinski
2011-08-21 16:23 ` Joseph S. Myers
2011-08-21 9:05 ` Matthias Klose
2011-08-22 18:51 ` Toon Moene
2011-09-06 6:57 ` Thomas Schwinge
2011-11-01 19:48 ` Marc Glisse
2011-11-02 0:53 ` Joseph S. Myers
2012-05-08 1:04 ` Matthias Klose
2012-05-08 13:21 ` Joseph S. Myers
2012-05-09 0:38 ` Matthias Klose
2012-05-09 13:37 ` Paolo Bonzini
2012-05-09 15:34 ` Matthias Klose
2012-05-09 16:29 ` Paolo Bonzini
2012-05-09 17:19 ` Matthias Klose
2012-05-10 6:42 ` Paolo Bonzini
2012-05-11 5:14 ` Matthias Klose
2012-05-11 10:51 ` Paolo Bonzini
2012-05-11 18:33 ` Matthias Klose
2012-05-12 22:09 ` Jonathan Nieder
2012-05-19 16:05 ` Thomas Schwinge
2012-06-06 14:28 ` Thomas Schwinge
2012-06-25 13:23 ` Matthias Klose
2012-06-25 14:00 ` Joseph S. Myers
2012-06-25 16:26 ` Matthias Klose
2012-06-28 10:31 ` Thomas Schwinge
2012-06-28 11:30 ` Matthias Klose
2012-06-28 11:41 ` Thomas Schwinge
2012-07-08 18:50 ` [patch v2] " Matthias Klose
2012-07-18 19:00 ` Thomas Schwinge
2012-07-19 1:12 ` John David Anglin
2012-07-19 3:19 ` David Miller
2012-07-19 15:14 ` Joseph S. Myers
2012-08-07 10:33 ` [ping] " Matthias Klose
2012-08-07 14:07 ` Ian Lance Taylor
2012-11-02 13:26 ` Matthias Klose
2012-11-02 17:37 ` Ian Lance Taylor
2012-11-04 15:45 ` Matthias Klose
2012-11-14 20:44 ` Ian Lance Taylor
2012-11-21 0:53 ` Matthias Klose
2012-11-15 11:44 ` Eric Botcazou
2012-11-15 11:58 ` Matthias Klose
2012-11-15 16:33 ` Eric Botcazou
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=4E504D21.7090709@ubuntu.com \
--to=doko@ubuntu.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=vorlon@debian.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).