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 b0adde8f8a.
Doesn't fix the issue for grsec kernels.
(cherry picked from commit 22bd9c12fe)
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
In most cases, this just meant changing kernelDev (now removed from
linuxPackagesFor) to kernel.dev. Some packages needed more work (though
whether that was because of my changes or because they were already
broken, I'm not sure). Specifics:
* psmouse-alps builds on 3.4 but not 3.10, as noted in the comments that
were already there
* blcr builds on 3.4 but not 3.10, as noted in comments that were
already there
* open-iscsi, ati-drivers, wis-go7007, and openafsClient don't build on
3.4 or 3.10 on this branch or on master, so they're marked broken
* A version-specific kernelHeaders package was added
The following packages were removed:
* atheros/madwifi is superceded by official ath*k modules
* aufs is no longer used by any of our kernels
* broadcom-sta v6 (which was already packaged) replaces broadcom-sta
* exmap has not been updated since 2011 and doesn't build
* iscis-target has not been updated since 2010 and doesn't build
* iwlwifi is part of mainline now and doesn't build
* nivida-x11-legacy-96 hasn't been updated since 2008 and doesn't build
Everything not specifically mentioned above builds successfully on 3.10.
I haven't yet tested on 3.4, but will before opening a pull request.
Signed-off-by: Shea Levy <shea@shealevy.com>
