[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
pgpiBI1w92DLp.pgp
Description: PGP signature
Re: [gforth] Running Gforth on Mips64el, David Kuehling, 2014/05/24