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)
|
> 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.