This adapter causes the resulting binaries to have debug info and no
optimisations. Example use (in all-packages.nix):
foo = callPackage ./foo.nix {
stdenv = keepDebugInfo stdenv;
};
If the environment variable HYDRA_DISALLOW_UNFREE is set to "1", then
evaluation of a package with license "unfree" will throw an error.
Thus such packages or any packages that depend on them will fail to
evaluate.
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
bash's pattern replacement feature. "replace-literal" is an
uncommon command so it was a headache during the bootstrap.
svn path=/nixpkgs/branches/stdenv-updates/; revision=31681
some redundant builds (e.g., GMP was built three times).
* Updated GMP to 5.0.2.
* Updated PPL to 0.11.2.
* Remove ad hoc flags to build GCC's dependencies statically.
Instead, use the ‘makeStaticLibraries’ stdenv adapter.
* Build GMP with C++ support by default.
svn path=/nixpkgs/branches/stdenv-updates/; revision=30891
These markers follow the format of those of `nix-store --print-build-trace',
which allows extraction of, say, phase durations in a similar way.
svn path=/nixpkgs/branches/stdenv-updates/; revision=26115
does not override NIX_CFLAGS_COMPILE anymore in the mkDerivation parameter
attributes. This way, apacheHttpd can be built properly with coverage
information.
An indication of this problem came from the nixos tests.subversion failure.
svn path=/nixpkgs/branches/stdenv-updates/; revision=24938
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
newest I uploaded yesterday. These have gcc 4.5.1, that fulfills the glibc
2.12.1 requirement of having a compiler equal or greater to gcc 4.4 to build
proper x86 32-bit code (http://sourceware.org/bugzilla/show_bug.cgi?id=12123)
svn path=/nixpkgs/branches/stdenv-updates/; revision=24523
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
Allowing 'curl' build without some dependencies, if it is told not to build
with them.
Updating the make-bootstrap-tools for the latest gcc/glibc, removing the
dependency on klibc, and updating unpack-boostrap-tools for the latest
boostrap-tools to work.
svn path=/nixpkgs/branches/stdenv-updates/; revision=23305
If a build expressions has set "enableParallelBuilding = true", then the
generic builder may utilize more than one CPU core to build that particular
expression. This feature works out of the box for GNU Make. Expressions that
use other build drivers like Boost.Jam or SCons have to specify appropriate
flags such as "-j${NIX_BUILD_CORES}" themselves.
svn path=/nixpkgs/trunk/; revision=23042
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
If a build expressions has set "enableParallelBuilding = true", then the
generic builder may utilize more than one CPU core to build that particular
expression. This feature works out of the box for GNU Make. Expressions that
use other build drivers like Boost.Jam or SCons have to specify appropriate
flags such as "-j${NIX_BUILD_CORES}" themselves.
svn path=/nixpkgs/branches/stdenv-updates/; revision=22399
"meta" and "passthru", and these attributes will be appended to the usual
mkDerivation attributes only if the package is cross built.
This allows putting some of the cross-building logic in the mkDerivation
nix parameters, and not only in the final builder script, as it was until now.
svn path=/nixpkgs/trunk/; revision=20272
* libpng updated to 1.4.0.
* For libjpegStatic, use a stdenv adapter to build a static library.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19605
I fixed conflicts regarding the renaming 'kernel' -> 'linux' in all-packages.
Also a small conflict in all-packages about making openssl overridable.
And I some linux 2.6.31-zen kernel files also marked in conflict.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19438
we can't build easily with them gcc-4.4 natively, because of a bug in the ld of the
previous bootstrap-tools.
I updated the unpack script to include the new gcc-4.4 libraries *ppl*.so in patchelfing.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18835
(dynamic libraries of ppl and cloogppl) into the package.
We need newer binutils in the bootstrap-tools for the armv5tel in order to
be able to build gcc 4.4 from them.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18747
renaming.
I think directory renaming breaks the usual merges... because it leaves the
'to be removed' directory in the working directory still. A manual 'rm' of the
'to be removed' directory fixed the commit.
svn merge ^/nixpkgs/trunk
svn path=/nixpkgs/branches/stdenv-updates/; revision=18661
this because 'ld' wants to know the path of every library involved in a dynamic
linking. I imagine that ld does not need that in native builds because it can
call the loader for it to resolve the library rpaths, but this is not the case
for cross-building.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18577
inputs did not get in)
Updating the xorg builder script to support cross building (in fact, support
for propagating the required build inputs).
svn path=/nixpkgs/branches/stdenv-updates/; revision=18569
- Disabling guile test, because one fails. I commented on that in the source.
On cross builds:
- Adding stripping
- Updating the glibc-2.11 expression to match the parameters of glibc-2.9,
which I was updating more.
- Renaming from selfNativeBuildInput to selfBuildNativeInput, so this matches
better the pattern buildNativeInputs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18550
- Before this changes, cflags and ldflags for the native and the cross compiler
got mixed. Not all the gcc-wrapper/gcc-cross-wrapper variables are
independant now, but enough, I think.
- Fixed the generic stdenv expression, which did a big mess on buildInputs and
buildNativeInputs. Now it distinguishes when there is a stdenvCross or not.
Maybe we should have a single stdenv and forget about the stdenvCross
adapter - this could end in a stdenv a bit complex, but simpler than the
generic stdenv + adapter.
- Added basic support in pkgconfig for cross-builds: a single PKG_CONFIG_PATH
now works for both the cross and the native compilers, but I think this
should work well for most cases I can think of.
- I tried to fix the guile expression to cross-biuld; guile is built, but not
its manual, so the derivation still fails. Guile requires patching to
cross-build, as far as I understnad.
- Made the glibcCross build to be done through the usage of a
gcc-cross-wrapper over the gcc-cross-stage-static, instead of using it
directly.
- Trying to make physfs (a neverball dependency) cross build.
- Updated the gcc expression to support building a cross compiler without getting
derivation variables mixed with those of the stdenvCross.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18534
