gforth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gforth] Running Gforth on Mips64el


From: David Kuehling
Subject: Re: [gforth] Running Gforth on Mips64el
Date: Sun, 25 May 2014 19:00:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

>>>>> "Anton" == Anton Ertl <address@hidden> writes:

>> Hm, this doesn't seem to be standardized well enough, the SuSE triple
>> looks wrong, and there's even a quadruple.
>> 
suse> gcc -dumpmachine
>> x86_64-suse-linux > arm-linux-androideabi-gcc -dumpmachine
>> arm-linux-androideabi > arm-none-linux-gnueabi-gcc -dumpmachine
>> arm-none-linux-gnueabi debian$ gcc -dumpmachine x86_64-linux-gnu

> The quadruple is a triple where the last component ("linux-gnu" and
> "linux-gnueabi") contains a "-".  The Suse triple looks ok (ok, Suse
> is no hardware vendor, but the vendor part is not that important these
> days anyway), the Debian triple looks wrong.

I think Debian just consistently omits the second part of the triple,
the "vendor" part (c.f. [1])

  mipsel-linux-gnu                (mipsel) 
  mips64el-linux-gnuabi64         (mips64el/N64)
  x86_64-linux-gnu                (amd64)

AFAIR various heuristics are usually in place (in configure scripts
etc.) to identify the last part of the triple, even in the ambiguous
case when vendor is missing and the last part contains a dash.  I.e. you
must never treat "linux" part as a vendor etc.  I think we would have to
reproduce these heuristics in case we expose the triplet in a decomposed
form.

David

[1] https://wiki.debian.org/Multiarch/Tuples 
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F

Attachment: pgpiBI1w92DLp.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]