SRFI 176: Version flag Arthur A. Gleckler (07 Oct 2019 05:01 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 18:43 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 20:26 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 20:50 UTC)
Re: SRFI 176: Version flag Lassi Kortela (07 Oct 2019 21:42 UTC)
Re: SRFI 176: Version flag John Cowan (07 Oct 2019 22:49 UTC)
Re: SRFI 176: Version flag Lassi Kortela (11 Oct 2019 23:40 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 03:40 UTC)
Re: SRFI 176: Version flag John Cowan (13 Oct 2019 04:23 UTC)
Re: SRFI 176: Version flag Arthur A. Gleckler (13 Oct 2019 04:53 UTC)
Re: SRFI 176: Version flag John Cowan (15 Oct 2019 12:20 UTC)
Storing manual pages and other data in executables Lassi Kortela (16 Oct 2019 20:39 UTC)
Re: Storing manual pages and other data in executables John Cowan (16 Oct 2019 21:36 UTC)
Re: SRFI 176: Version flag Shiro Kawai (13 Oct 2019 05:24 UTC)
Storing manual pages and other data in executables Lassi Kortela (14 Oct 2019 11:56 UTC)
Re: Storing manual pages and other data in executables John Cowan (14 Oct 2019 16:33 UTC)
Re: Storing manual pages and other data in executables Lassi Kortela (17 Oct 2019 17:06 UTC)
Gory details of parsing Lassi Kortela (07 Oct 2019 21:04 UTC)
Re: Gory details of parsing John Cowan (07 Oct 2019 23:05 UTC)
Re: Gory details of parsing Lassi Kortela (11 Oct 2019 23:50 UTC)
Re: Gory details of parsing John Cowan (15 Oct 2019 01:52 UTC)
Working out the platform and compiler info Lassi Kortela (14 Oct 2019 16:52 UTC)
Clarification of tuples Lassi Kortela (14 Oct 2019 17:09 UTC)
Re: Working out the platform and compiler info John Cowan (14 Oct 2019 18:07 UTC)

Clarification of tuples Lassi Kortela 14 Oct 2019 17:09 UTC

> The platform 4-tuple is stolen from
> <https://wiki.debian.org/Multiarch/Tuples> as faithfully as possible
> (currently, not very). If you go to that page, they have done an
> excellent job mapping loads of 4-tuples covering numerous platforms. We
> should probably just adopt their approach.
>
> So their 4-tuple is (kernel userland computer endian) as above.

I didn't explain myself properly. The IDs on that page are written like:

mips64el-linux-gnuabin32

So that's only three components. But mips64el means MIPS64 and
little-endian, so that's two components of the 4-tuple joined into one.

Their table also has a fifth column for the word size (32 or 64); it's
up for debate whether it should be part of the CPU architecture name or
be separate. I don't have an opinion and would be interested in hearing
arguments for either choice.