We now have an alternate setup hook for gcc-wrapper that uses -I to add
include paths rather than -isystem. The latter flag can change the
search order specified by the build system. For KDE 5 packages, we don't
want that!
The default setup-hook for gcc-wrapper adds include directories with
-isystem, which upsets the order -I flags are processed. This adds an
alternative setup-hook that only uses -I flags. The build system's
ordering of -I flags is then respected. This is important when different
packages provide includes with the same name, such as building packages
that depend on Qt4 and Qt5.
We still need this because some clang-based packages depend on
it. (The sysroot filtering was originally done by clang-wrapper's
ld-wrapper, but we merged the ld-wrappers in
a4f9b9c8b5ec9ef106671ffdf93e0059835d0ec1.)
http://hydra.nixos.org/build/13906922
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.
Now gcc is just another build input, making it possible in the future
to have a stdenv that doesn't depend on a C compiler. This is very
useful on NixOS, since it would allow trivial builders like
writeTextFile to work without pulling in the C compiler.
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.
The gcc-wrapper doesn't wrap 'cpp'. This breaks some software (such as
Buildroot) because the 'cpp' they get come from the non-wrapped gcc
package which doesn't know about any standard include paths.
gcc-cross-wrapper is untested.
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).
This feature sounds crazy, but it is used in some configure scripts (e.g. xbmc).
This patch causes an almost complete rebuild of Nixpkgs.
Patch submitted by Jan Malakhovski <oxij@oxij.org>.
what the new nix thinks the fuloong is.
Anyone having the old nix should use a nixpkgs previous to this change to build
the new nix. And then, with the new nix, he can use any newer nixpkgs revision.
svn path=/nixpkgs/trunk/; revision=31751
path worth a "-rpath" entry.
This put a problem in the bootstrap, where we built 'zlib' and wanted to link programs with it, and while they got linked well, at runtime the boostrap-tools zlib came first on rpath becaue
the ld call was done with "-dynamic-linker ..." before "-lz".
I saw this trouble on the fuloong, where the zlib in boostrap-tools is not
runtime compatible with that binutils are linked to.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25107
derivation instead of a string, but this did not cover all use cases we had.
Instead of updating the use cases, I made the wrapper accept also a string.
We saw this problem trying to build gcc43_multi.
svn path=/nixpkgs/branches/stdenv-updates/; revision=25029
