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
it properly put the rpath for directly passed .so files, and additionally it
works much faster than the old ld-wrapper.
svn path=/nixpkgs/branches/stdenv-updates/; revision=21978
on the next stdenv-updates.
This would fix the build for many cmake packages, although that requires updating the stdenv
in those for its gcc to use this 2nd wrapper.
I updated paraview and avidemux. I can't recall now more packages with problems, but I was
quite sure there were.
If anyone sees a cmake-built package with the result binaries lacking some rpaths, then try
this wrapper.
svn path=/nixpkgs/trunk/; revision=20669
because it makes linking very slow. Use bash's =~ operator instead
(and only once for each argument). We depend on bash already anyway
because of arrays so it's not a problem.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19699
something'.
It should not link at least for '-x c-header' and '-x c++-header', and maybe
link for '-x c' or '-x c++', but we expect noone will be linking using these
later strings.
Adding opencv, which required '-x c-header' working, and that's why I have
updated gcc wrapper.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19491
regexp looking for such ld arguments did not work well with "--soname=xxx.so".
Now I added the condition that the argument should not start with a hyphen, for
it to be possibly considered a .so file to link with.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18919
Removing any reference to the gcc-wrapper2, as now the gcc-wrapper already conveys
the changes, I created gcc-wrapper2 in trunk for.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18913
This comes from:
svn diff ^/nixpkgs/trunk/@18255 ^/nixpkgs/branches/stdenv-updates/ > diff
patch -p0 < diff
and then adding into svn all files new from the patch.
trunk@18255 comes from the last time I updated stdenv-updates from trunk.
svn path=/nixpkgs/stdenv-updates2/; revision=18272
