Re: [patch] support for multiarch systems

[Matthias Klose <doko at ubuntu dot com>]

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