Our coreutils now uses single-binary-build mode where, by default,
simple shebang scripts are used for all the binaries. That doesn't work
e.g. with the Linux unpacker which only handles standard binaries and
symlinks. Let's use the symlinked mode instead for boostrapping.
This does NOT change any stdenv hashes.
I only tested the case most important to me:
$ nix-build pkgs/top-level/release.nix -A stdenvBootstrapTools.x86_64-linux.test
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
The patch no longer applies as it's applied in the 8.25 release.
While at it don't use FORCE_UNSAFE_CONFIGURE on ARM as I don't see why
it's needed and it works for me without it.
Build-tested GNU hello on ARMv7 and verified that this affect its hash
on i686.
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.
It was using 'null' instead of '[]' in case of no patches. So I change
it to provide 'null'.
(cherry picked from commit 56ff659e5d1fffd371786a3b8237129ee365ca5c)
I pick the patch from upstream, and I apply only for ARM to avoid rebuilding
stdenv.
(cherry picked from commit 1b36f489b6fb2bde3b241d2763abfaa860a4fe55)
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
Also some style cleanup.
Note that defining an empty-string variable *does* change the hash.
I would like to change this behaviour one day
(clean up attrs when compiling the derivation).
From https://lists.macosforge.org/pipermail/macports-dev/2011-July/015263.html:
5) Building with a compiler that doesn't support newer __builtins
If your port uses MacPorts compilers rather than the default compiler,
you may run into trouble with string functions. You'll see errors at
link time about undefined __builtin_* functions. If this happens, you
may want to compile with -D_FORTIFY_SOURCE=0 to tell the headers to
use unfortified versions which do not use compiler builtins.
