...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.
This fixes the gcc build but results in a gcc that doesn't generate
valid binaries.
gcc -o hello hello.c
./hello
Killed: 9
This reverts commit 2adf36ab8c.
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
stdenv.cross is a silly attribute that needs to go leaving the well-defined hostPlatform and targetPlatform. This PR doesn't remove it, but changes its definition: before it tracked the target platform which is sometimes more useful for compilers, and now it tracks the host platform which is more useful for everything else. Most usages are libraries, falling in the "everything else" category, so changing the definition makes sense to appease the majority. The few compiler (gcc in particular) uses that exist I remove to use targetPlatform --- preserving correctness and becoming more explicit in the process.
I would also update the documentation aside mentioning stdenv.cross as deprecated, but the definition given actually erroneously assumes this PR is already merged!
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 eliminate the branched logic for gfortran on Darwin, as well
as preventing accidental inclusion of impure paths in gcc and gfortran
builds.
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.
- disable bootstrap builds on Darwin
- remove xcrun calls
- check if patchelf is available before using
- apply darwin patch for gcc4.9
- fixes #16047
- fixes #14812
