See previous commit for what was done to `binutils` to make this
possible.
There were some uses of `forcedNativePackages` added. The
combination of overrides with that attribute is highly spooky: it's
often important that if an overridden package comes from it, the
replaced arguments for that package come from it. Long term this
package set and all the spookiness should be gone and irrelevant:
"Move along, nothing to see here!"
No hashes should be changed with this commit
The previous commit redefines `stdenv.cross` for the sake of normal
libaries, the most common use-case of that attribute. Some compilers
however relied on the old definition so we have them use
`targetPlatform` instead. This special casing is fine because we
eventually want to remove `stdenv.cross` and use either `hostPlatform`
or `targetPlatform` instead.
This should get gcc48, gcc5, and gcc6 working again.
Also: use makeLibraryPath, and makeSearchPathOutput for LIBRARY_PATH and
CPATH. This is a refactor but it also fixes an issue with zlib.
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
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).
Sometimes the build failes with:
In file included from ../../gcc-4.4.6/gcc/ada/seh_init.c:44:
../../gcc-4.4.6/gcc/system.h:418: error: conflicting types for 'strsignal'
/nix/store/6h129q168ahnl2nzw6azr239cba884ng-glibc-2.18/include/string.h:560: note: previous declaration of 'strsignal' was here
and sometimes it doesn't. Hopefully disabling parallel builds fixes
this.
http://hydra.nixos.org/build/7179481
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
