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
- 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.
Attrnames and package names should be as close as possible to avoid confusion.
I took care not to confuse the two mpc things during the mass-replace,
so hopefully I suceeded (tarball still builds).
For now, we don't NATIVE_SYSTEM_HEADER_DIR because it breaks the
build. However, it points to Glibc in the Nix store (not /usr/include)
so it's kind of okay.
Even if using profiledbootstrap. This was unsafe before 4.8, and
then the documentation was not fixed on time.
The documentation got fixed here:
c763997f34
But the actual code was already fixed here:
5d2fca09d5
So this is safe both for GCC 4.8 and GCC 4.9.
Having a separate lib64 is bad because it requires special-casing in
lots of places.
Previously done in e4a11b4d92424c42f61ee55cf505ac1217944f4a, which
apparently got lost going from 4.6 to 4.8.
Recent versions of Xcode don't install headers in /usr/include but
in a directory like
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
So use that instead, falling back to /usr/include in case of an older
version of Xcode.
Somewhere the no-sys-dirs.patch got disabled, so gcc was looking in
/usr/local/include and /usr/lib. Since I can't fix the patch easily,
I've borrowed the --sysroot trick from clang-wrapper. This causes
builtin paths to be prefixed with /var/empty
(e.g. /var/empty/usr/lib), which don't exist.
