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
I thought I didn't change stdenv, but I did. This will go soon into the stdenv
branch then.
Reverse-merging r16467 through r16465.
svn path=/nixpkgs/trunk/; revision=16468
works on Red Hat Linux, i.e. that is based on glibc version 2.5.
Furthermore, this patch fixes a number of gcc 4.3.3 build errors in glibc 2.5
that occur on both x86 and x86_64. The older version of this library is still
useful for running Nix on a Red Hat host. Newer version of glibc fail to detect
the kernel's capabilities correctly (due to mad patches applied to the kernel
by Red Hat).
The individual changes are:
* Re-activated glibc 2.5 in all-packages.nix.
* Fix incomplete header search path in bootstrap tools.
Gcc-wrapper sets "-B<prefix>" to tell the compiler about its installation
root. Unfortunately, the setting doesn't add $gcc/lib/gcc/*/*/include-fixed
to the search path. That directory is required, however, because it contains
the system-specific "limits.h" file, and the glibc 2.5 builds tries to find
that file via #include_next.
* Support intrinsic functions like __signbit() or atof() correctly to avoid
compile-time conflicts.
* Switch to NPTL. Linuxthreads is no longer supported.
* Added a meta attribute to glibc package.
* Updated nixUnstable to version 0.13pre15614 from trunk. The previous version
failed regression tests.
* Fix more strict type checking in binutils since 2.18.50.0.3.
Without this patch, the build failed on x86, saying:
../sysdeps/i386/fpu/ftestexcept.c: Assembler messages:
../sysdeps/i386/fpu/ftestexcept.c:33: Error: suffix or operands invalid for `fnstsw'
svn path=/nixpkgs/branches/stdenv-updates/; revision=16037
builders. These are redundant now.
* Inlined some trivial builders.
* Removed a few explicit setup-hook creations. This is done
automatically now if setupHook is set.
* Deleted the initscripts package. NixOS doesn't use it anymore.
svn path=/nixpkgs/branches/stdenv-updates/; revision=15276
* setup.sh: removed some obsolete features, specifically some that
were only used by the old build farm.
* addToSearchPath: removed some parameters that weren't used
anywhere.
svn path=/nixpkgs/branches/stdenv-updates/; revision=15136
instead of "gcc-4.3.3". This fixed the long-standing annoyance that
you can't distinguish the two in (say) nix-store -qR.
* On x86_64-linux, put $out/lib64 in the RPATH in addition to
$out/lib, because some packages (in particular GCC) put libraries in
$out/lib64 and ended up linking against the wrong library.
* Strip $out/lib64.
* Removed g77_42 because it's exactly the same as gfortran.
svn path=/nixpkgs/branches/stdenv-updates/; revision=14708
* Put the Glibc linker flags in front of the GCC linker flags. Needed
for the stdenv-linux bootstrap.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13940
should fix previous problems with GCC 4.3 in compiling C++ code
where e.g. <cassert> has to appear before <assert.h> in the search
path due to the former's use of #include_next. The previous "fix"
broke compilation of C code by placing the C++ include directory
before the Glibc include directory (which would barf on
e.g. <complex.h>, which appears in both).
svn path=/nixpkgs/branches/stdenv-updates/; revision=13806
can be installed in a user environment without conflict. This is
useful if you need gcov (which isn't symlinked in the GCC wrapper).
svn path=/nixpkgs/trunk/; revision=8809
* Removed substitute, it's part of the generic builder now.
* stdenv-initial (Linux): use the real generic builder script. This
does require that sed is in the path of the builder of the initial
stdenv.
svn path=/nixpkgs/trunk/; revision=7498
we use the GCC wrapper in a user environment, the wrong assembler
will be called. This is not usually a problem, but sometimes it is
(e.g., when using G++ 4.1.1 with binutils 2.16 or so).
svn path=/nixpkgs/trunk/; revision=6862
