The current version of glibc implements support for kernels down to
3.2.0 (and we make sure to enable such support with apporopriate
--enable-kernel setting). The current RHEL6 operating system is based on
a maintained kernel based on 2.6.32 with lots of backports. We provide
basic support for this specific kernel by patching glibc to provide an
exception for this specific version of kernel. This allows for nixpkgs
software distribution to work on RHEL6 and it does so quite well with
almost no problems. There are, however, a few syscalls that are missing
in the 2.6.32 kernel, one of which is prlimit64. This commit provides a
fallback that uses an older {get,set}rlimit syscalls in cases when
prlimit64 is not available. This should streamline the experience for
nixpkgs users wanting to run it on RHEL6, namely, this fixes one of the
tests in findutils.
See also discussion in guix:
https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00356.html
It's certainly better to have those two caveats than not evaluate.
Both seem rather niche. Unfortunately I failed to find a better way.
I started testing builds of several cross variants; all seem OK.
References to the host toolchain are leaking through debug symbols in
glibc, causing gnu cross-builds to always depend on the host toolchain.
The decision to not strip was made in 2012 in order to improve GNU/Hurd
support, and I suspect the reasons that justified it back then do not
apply anymore in 2019.
Closure size before:
/nix/store/v5pxj0bgg627hic2khk4d43z6cjp5v7d-hello-2.10-armv7l-unknown-linux-gnueabihf 596.8M
After:
/nix/store/llp1ncmpar406rc2vhj7g5ix4yqwna3n-hello-2.10-armv7l-unknown-linux-gnueabihf 23.6M
This round is without the systemd CVE,
as we don't have binaries for that yet.
BTW, I just ignore darwin binaries these days,
as I'd have to wait for weeks for them.
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.
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
