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).
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
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
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
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
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
Glibc. This is useful when building GCC.
* gcc-wrapper: the dynamic linker has a different name on x86_64 and
powerpc.
* gcc-wrapper: "glibc" -> "libc", because someday we might support
different C libraries.
* gcc: don't do a multilib build (e.g., 32-bit support on x86_64),
don't need it.
* gcc: merge in support for static builds.
* gcc: various simplifications in the compiler/linker flags, hope they
work.
svn path=/nixpkgs/trunk/; revision=6823
contains arbitrary information about a package, like this:
meta = {
homepage = "http://gcc.gnu.org/";
license = "GPL/LGPL";
description = "GNU Compiler Collection, 4.0.x";
};
The "meta" attribute is not passed to the actual derivation
operation, so it's not a dependency --- changes to "meta" attributes
don't trigger a recompilation.
Now we have to standardise some useful attributes ;-)
svn path=/nixpkgs/branches/usability/; revision=5024
On the downside, the build process of stdenvLinux builds gcc 9 times
(3 x 3 bootstrap stages). That's a bit excessive.
svn path=/nixpkgs/trunk/; revision=880
* Make builders unexecutable by removing the hash-bang line and
execute permission.
* Convert calls to `derivation' to `mkDerivation'.
* Remove `system' and `stdenv' attributes from calls to
`mkDerivation'. These transformations were all done automatically,
so it is quite possible I broke stuff.
* Put the `mkDerivation' function in stdenv/generic.
svn path=/nixpkgs/trunk/; revision=874
checked whether absolute paths passed to gcc/ld refer to the store,
which is wrong: they can also refer to the build tree
(/tmp/nix-...).
* Less static composition in the construction of stdenv-nix-linux:
gcc-wrapper and generic are now passed in as arguments, rather then
referenced by relative path. This makes it easier to hack on a
specific stage of the bootstrap process (before, a change to, e.g.,
generic/setup.sh would cause all bootstrap stages to be redone).
svn path=/nixpkgs/trunk/; revision=833
- gcc/ld-wrappers have been factored out into a separate
derivation. This allows a working gcc to be installed in the user
environment. (Previously the Nix gcc didn't work because it
needed a whole bunch of flags to point to glibc.)
- Better modularity: packages can specify hooks into the setup
scripts. For instance, setup no longer knows about the
PKG_CONFIG_PATH variable; pkgconfig can set it up instead.
- gcc not longer depends on binutils. This simplifies the bootstrap
process.
svn path=/nixpkgs/trunk/; revision=816
