Because if you get it wrong, you get a very confusing error message at
the end of the kernel build, which is quite painful as the build can
take a long time.
[dezgeg: note that we are currently using just 'Image' instead of
'Image.gz' as U-Boot doesn't support the latter yet. We might switch
once it does since the kernel images are quite big]
It takes some extra 13MB (and in dev, not out), but allows perf to show kernel
symbols when profiling. I think it is worth it.
In my NixOS, I refer to it in the system derivation, for easy telling to perf
through /run/booted-system/vmlinux:
system.extraSystemBuilderCmds = ''
ln -s ${config.boot.kernelPackages.kernel.dev}/vmlinux $out/vmlinux
'';
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
Since commit 48f51f1185 we let the kernel build system compress the
modules, which makes the original strip expression not work. Let the
kernel build system strip them as well so they get stripped.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
The current default multiple-output propagation rules don't seem to work
too well if the dev output isn't the first one; without this we get an
unnecessary runtime reference to the kernel headers.
I added platform.kernelMakeFlags. This allows setting the required
parameter to make the required kernel uImage for the sheevaplug,
since it became a platform with devicetree (3.10).
I have tried it with linux 3.18 and it built fine.
When building kernels outputting a zImage, the zImage wasn't correctly copied in
to the installation. This broke the build process entirely, at least on my ARM
machine.
Testing showed the linux build is sensitive to /usr/include/ncursesw
unless chrooted (on non-nixos).
On a single chrooted nixos machine, -A linux is binary reproducible.
CC #2281 & @alexanderkjeldaas.
Based on access analysis with strace, I determined an essentially
minimal required set of files from the kernel source that was needed to
build all current kernel packages on 3.10, which ultimately resulted in
keeping 30M of source. Generalizing from that minimal set, which
required ad-hoc specifications of which headers outside of include/ and
arch/*/include and which files in the scripts/ directory should be kept,
to a policy of keeping all non-arch-specific headers that aren't part of
the drivers/ directory and the entire scripts/ directory added an
additional 17M, but there was nothing in the analysis that indicated
that that ad-hoc specification was at all complete so I think the extra
hit is worth the likely greater compatibility.
For reference, we now keep:
* All headers that are NOT in arch/${notTargetArch}/include or drivers/
* The scripts/ directory
* Makefile
* arch/${targetArch}/Makefile
IMO the most likely cause of future problems are the headers in
drivers/, but hopefully they won't actually be needed as they add 50M
Ideally kernel packages would only use include and
arch/${targetArch}/include, but alas this is observably not the case.
master:
* $out
* size: 234M
* references-closure: linux-headers, glibc, attr, acl, zlib, gcc,
coreutils, perl, bash
merge-kernel-builds:
* $out
* size: 152M
* references-closure: none
* $dev
* size: 57M
* references-closure: linux-headers, glibc, zlib, gcc
So even with the non-minimal set we still beat out master. Keeping the
drivers headers would make us only slightly bigger.
Signed-off-by: Shea Levy <shea@shealevy.com>
