- NIX_CC_CROSS is now completely gone!
- NIX_CC is defined reliably, so no manual def needed
- stdenv.ccCross -> stdenv.cc, also removing need for "or" fallback
Previously configureFlags was defined as one giant interpolated string.
Here we refactor this definition to instead use the usual stdenv string
combinators. This seems more in-line with the average nixpkgs expression
and it seems a bit more natural to things of these as lists of flags
rather than monolithic strings.
One should do this when needed executables at run time. It is more
honest and cross-friendly than refering to binutils directly, if one
neeeds the default binary tools for the target platform, rather than
binutils in particular.
...just as we did for binutils. When the underlying issue is resolved
(probably with a configure script patch or lib/systems/parse.nix
change), this should be reverted.
Host everywhere would be guaranteed to preserve the old semantics,
but in a few places it doesn't matter in practice, target is used
instead for clarity.
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.
Darwin systems need to be able to find CoreFoundation headers as well as
libc headers. Somehow, gcc doesn't accept any "framework" parameters
that would normally be used to include CoreFoundation in this
situation.
HACK: Instead, this adds a derivation that combines the two. The result
works but probably not a good long term solution.
ALTERNATIVES: Maybe sending patches in to GCC to allow
"native-system-framework" configure flag to get this found.
gcc needs to be able find system headers. Without this, gcc fails to build because
/usr/include is not available.
Note: stdenv.libc should be available for all stdenv's, I think.
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.
