bootstrap-tools, because zlib was there and binutils were not having an
explicit buildInput for zlib. Due to that, we ended up with stdenv
(gcc-wrapper) depending on bootstrap-tools as runtime dependency.
svn path=/nixpkgs/branches/stdenv-updates/; revision=24790
had a little svn mess in the working directory that ended up in a not working
stdenvLinux.
This time I even chose better names for the attributes, so they match better
the comments.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23428
I had done an attempt recently, unsuccesful, which ended in a recent revert.
This change works.
I even updated the comments in the file.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23425
What I did results in segfaults in built binaries.
svn merge -c -23370 ^/nixpkgs/branches/stdenv-updates
svn path=/nixpkgs/branches/stdenv-updates/; revision=23376
This should allow keeping the i686-linux boostrap-tools.
I updated some days ago the x86_64-linux bootstrap-tools, but that update is
not needed anymore. We can revert that boostrap-tools update if anyone wants.
Pro:
- new gcc building gcc and glibc.
Contra:
- maybe some old systems (patched red had kernels come to mind) break with that update?
svn path=/nixpkgs/branches/stdenv-updates/; revision=23370
Instead, use the generic package override mechanism to use packages
from earlier bootstrap phases.
* Don't rely on the existence of attributes such as
`stdenv.coreutils'.
svn path=/nixpkgs/trunk/; revision=22991
the cross compilation functionality.
- I renamed some expected stdenv.mkDerivation parameter attributes so we can
keep this branch properly updated from trunk. We agreed with Nicolas Pierron
doing a massive renaming, so all current buildInputs become hostInputs (input
as build for the host machine, in autotools terminology) , and
then buildInputs would mean "input as for the build machine".
By now, the specific "input as for the build machine" is specified through
buildNativeInputs. We should fix this in the merge to trunk.
- I made the generic stdenv understand the buildNativeInputs, otherwise if
we start changing nixpkgs expressions so they distinguish the current
buildInputs into buildInputs and buildNativeInputs, we could break even more
nixpkgs for other platforms.
- I changed the default result of mkDerivation so it becomes the derivation for
to be run in the build machine. This allows, without any special rewriting,
"fetchurl" derivations to be always results for the build machine to use
them.
- The change above implies that, for anyone wanting to cross-compile, has to
build the hostDrv of the wanted derivation. For example, after this commit,
the usual test of "nix-build -A bison.hostDrv arm.nix" works. I described
the contents of this arm.nix in r18398.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18471
It still does not work, but I think I already get glibc cross compiled.
Next: gcc and g++, and set some setup script hooks on stdenvCross.
It took quite enough hours for this commit.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18351
My idea is to provide special stdenv expressions that will contain in the path
additional cross compilers. As most expressions for programs accept a stdenv parameter,
we could substitute this parameter with the special stdenv, which will have a
generic builder that attempts the usual "--target=..." and can additionally
have an env variable like "cross" with the target architecture set.
So, finally we could have additional expressions like this:
bashRealArm = makeOverridable (import ../shells/bash) {
inherit fetchurl bison;
stdenv = stdenvCross "armv5tel-unknown-linux-gnueabi";
};
Meanwhile it does not work - I still cannot get the cross-gcc to build.
I think it does not fill the previous expressions with a lot of noise, so I
think it may be a good path to follow.
I only touched some files of the current stdenv: gcc-4.3, kernel headers
2.6.28, glibc 2.9, ...
I tried to use the gcc-cross-wrapper, that may be very outdated. Maybe I will
update it, or update the gcc-wrapper expression to make it fit the cross tools,
but meanwhile I even cannot build gcc, so I have not tested the wrapper.
This new idea on cross compiling is not similar to that of the
nixpkgs/branches/cross-compilation, which mostly added bare new expressions for
anything to be cross compiled, if I understood it correctly.
I cared not to break anything of the usual stdenv in all this work.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18343
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
LD_LIBRARY_PATH since it breaks /bin/sh on non-NixOS platforms (and
reverted the previous "fix" in r15470).
svn path=/nixpkgs/branches/stdenv-updates/; revision=16029
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
* Updated stdenv-linux:
- The bootstrap tools are no longer statically linked (except for
binaries in the Nixpkgs tree used to download and unpack the
bootstrap tools).
- x86_64 uses the same static binaries as i686. This makes the
Nixpkgs tree a bit smaller.
- Use the Linux 2.6.28 headers.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13946
setting the NIX_INDENT_MAKE variable; disabled by default) so we
don't need a separate gnumakeNix package.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13807
bootstrap wasn't recycled in the final allPackages, causing an
additional glibc to be built for packages that explicitly depend on
glibc.
svn path=/nixpkgs/trunk/; revision=12200
* Some fetchurl-related refactoring. The `realCurl' attribute is
gone, `curl' is the real thing. To prevent an infinite recursion in
`fetchurl' (because it depends on curl and building curl needs
fetchurl), curl and its dependencies (openssl, zlib, perl) use
`fetchurlBoot', which is the fetchurl used by the previous bootstrap
phase (e.g. the statically linked version of curl for
stdenv-linux). So as a result you can use https:// urls almost
everywhere.
There's also some hackery to prevent a different curl from being
built in every stdenv-linux bootstrap phase (namely the
stdenv.fetchurl attribute which allows fetchurl to be overriden
everywhere).
svn path=/nixpkgs/trunk/; revision=11905
* 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
all-packages. That is, an attribute like "bash" in all-packages.nix
should evaluate to the "bash" used to build stdenv, it shouldn't
build a new one.
Hm, this would be a lot cleaner if we had lazy_rec ;-)
svn path=/nixpkgs/branches/usability/; revision=4775
$glibc/lib/gconv/ISO-2022-JP.so has an RPATH of `$ORIGIN' so that it
can find glibc/lib/gconv/libJIS.so; `$ORIGIN' should not be filtered
out of the RPATH).
svn path=/nixpkgs/trunk/; revision=2290
* Combine most of the archives together into one file (static.bz2).
* Don't depend on Subversion directories, but single files only.
Otherwise any Subversion operation may cause a rebuild because
something in .svn changes. It would be nice if .svn directories
were filtered out when copying things to the store.
* Glibc tarball: removed all .so files, /bin and /sbin, etc., and put
linux-headers in the Glibc tarball.
svn path=/nixpkgs/trunk/; revision=2265
