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.
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
While it is easy to make a custom kernel by applying kernelPatches it is
not so easy to get the corresponding headers; the derivation uses a
hard-coded kernel version.
This makes us less reliant on the systems/examples.nix. You should be
able to cross compile with just your triple:
$ nix build --arg crossSystem '{ config = "armv6l-unknown-linux-gnueabi"; }' stdenv
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.
It's not actually needed, and AFAICT has never been. Or at least
Buildroot can build kernel headers as old as 3.2 without running the
config phase.
While at it, set ARCH unconditionally.
@dezgeg was right: The `platform` field of a linux platorm is already
manadatory---if not specified it is inferred, and all such inferences
include a `kernelArch` field. Therefore linux packages can indeed rely
on it being defined.
- Perl is used at build time, so must be in `nativeBuildInputs`. It's
not used at run time so it should not be in `buildInputs`, too.
- Don't treat headers like a compiler---use the build and host
platforms not host and target. Perhaps that would make sense if every
library's headers could be a separate derivation, but since that is
not feasible, best to keep the implementation and interface in the
same stage.
To do this, we used `stdenvNoCC` to get rid of the normal toolchain,
and added a dependency for the toolchain targeting the build platform
--- `buildPackages.stdenv.cc` --- thus everything is effectively slid
a stage black.
Extracting headers from a grsecurity patched kernel triggers additional
build steps that require gcc plugins. For this to work, we'd need to
add gmp, libmpfr, and libmpc to the build inputs as well as run `make
prepare` before installing the headers (lest the build fail due to
missing files).
Out-of-tree modules use kernel.dev and user space should use the Linux
API headers used to build libc, not headers extracted from random
kernels, so fixing this for grsecurity is pointless.
This reverts commit b0adde8f8a5f22cf45f32df64bba149f326dec85.
Doesn't fix the issue for grsec kernels.
(cherry picked from commit 22bd9c12fec43bf914cdbec4c3a11cd0d964912a)
Signed-off-by: Domen Kožar <domen@dev.si>
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
