Carefully fake cc-version and cc-fullversion to avoid needing a compiler
for the kernel itself to build the headers.
For some reason, doing `make install_headers` twice, first without
INSTALL_HDR_PATH=$out then with, is neccessary to get this to work.
The hack of using `crossConfig` to enforce stricter handling of
dependencies is replaced with a dedicated `strictDeps` for that purpose.
(Experience has shown that my punning was a terrible idea that made more
difficult and embarrising to teach teach.)
Now that is is clear, a few packages now use `strictDeps`, to fix
various bugs:
- bintools-wrapper and cc-wrapper
ARM ABIs now have a float field. This is used as a fallback to lessen
our use of `platform.gcc.float`. I didn't know what the MIPs convention
is so I kept using `platform.gcc.float` in that case.
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae5048)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
The glibc package does not respect a standard convention to put the
executables in the first output which should be as clear as possible
to anyone seeking to use such executables (e.g. `ldd`). This commit
adds a detailed comment a the top of `common.nix` explaining the
deviation from the convention and how to reference the binaries.
Security: the NEWS claims a couple more CVEs are fixed than what we
patched, though perhaps nothing critical.
I personally don't find DNS fragmentation attacks that interesting
anymore, as it's just about weaker improvements for cases that choose
not to use DNSSEC.
Largest expected caveat: upstream bumped the minimal supportable kernel
to 3.2.0. That's the oldest kernel still supported upstream, released
in Jan 2012, but most notably RHEL 6 and derivates still use a heavily
patched 2.6.32 kernel and those systems are still supported and in use
(production support is scheduled to last till the end of 2020!).
In #28519 / 791ce593ce I made linux
headers be intended to be used from the stage stage, as it would be if
it were a library containing headers and code. I forgot to update glibc,
however, so it was incorrectly using headers for the build platform, not
host platform.
This fixes that, basically reverting a small portion of changes I made a
few months ago in 25edc476fd and its
parent.
No native hashes are changed.
