Add an explicit dependency on netbase for /etc/protocols
Certain functions in glibc look for files present in /etc such as getprotobyname which reads /etc/protocols.
If you are using Nix over a Linux installation, this file may not be present, and therefore it will cause errors.
- add netbase as a new package in nixpks
- add a dependency in glibc on it using postPatchPhase and substitute
the path
Fixes#124401
This enables ALSR on static executables, which makes them harder to
exploit by providing a crt suitable for static PIEs.
Does this break existing binaries? Likely not. Static-pie is only
used if explicitly enabled.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
Fixes cross-compilation when build == host != target == ppc64le.
Glibc invokes objcopy during cross-compilation to ppc64le, which
fails when the nonprefixed objcopy can't understand the target format.
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
Pythons find_library is broken with binutils 2.34, and numpy could not import libraries because of not properly aligned ELF's.
This is the second time binutils 2.34 got reverted. Next time, we should have a dedicated Hydra job for it.
This reverts commit 629fa8a2d4, reversing
changes made to 4ddd080d19.
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.
