For a while now, the only thing the 'uboot' attribute does is to tell
whether to add ubootTools to kernel/initrd builds. That can be
determined with platform.kernelTarget == "uImage" just as well.
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.
