On Sun, May 25, 2014 at 03:11:17PM +0200, Bernd Paysan wrote:
> Am Sonntag, 25. Mai 2014, 05:03:51 schrieb David Kuehling:
> > After some more googeling I think the right approach would be to give
> > Gforth programs access to the host triplet that defines CPU, OS and ABI.
Yes.
> > Shall we just expose the full value returned by 'gcc -dumpmachine' or
> > split it into CPU and OS components as done by AC_CANONICAL_HOST?
>
> 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 would suggest to have separate the triple so that you can query the
> processor, the OS and the ABI separately. E.g. the typical place for OS is
> OS-specific calls or structures in C bindings, and you usually don't care if
> that is one or the other ABI.
Yes, if we have consistent component names, splitting and doing STR=
on the components would be the way to go. As it is, I wonder if it
wouldn't be better to provide the whole string and then use SEARCH to
check for the architecture and/or the OS/ABI.
- anton
