Updating the cross-build expressions, adding some flexibility.
Updated the linux headers used cross building, as 2.6.28 had bugs on endianness in
sparc64.
There were, as usual some bugs in gcc. Maybe not many make a cross compiler to
ultrasparc.
For the record, I could build an ultrasparc kernel with this base nix:
import /etc/nixos/nixpkgs/default.nix # The root nixpkgs default.nix
{
crossSystem = {
config = "sparc64-unknown-linux";
bigEndian = true;
arch = "sparc64";
float = "soft";
withTLS = true;
cpu = "ultrasparc";
};
config = pkgs: {
packageOverrides = pkgs : {
platform = {
name = "sparc64";
kernelHeadersBaseConfig = "sparc64_defconfig";
kernelBaseConfig = "sparc64_defconfig";
kernelArch = "sparc";
kernelAutoModules = false;
kernelTarget = "zImage";
uboot = null;
};
};
};
}
Although it did not boot directly in qemu-system-sparc64:
[sparc64] Kernel already loaded
Unhandled Exception 0x0000000000000020
PC = 0x0000000000404000 NPC = 0x0000000000404004
svn path=/nixpkgs/trunk/; revision=20269
sheevaplug kernel, so the kernel does not build in the sheevaplug right now.
I will try to fix that in next commits.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19045
- 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
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
* Kernel headers 2.6.27. However, they don't work yet because they
have a Perl dependency, which is annoying during the bootstrap.
svn path=/nixpkgs/branches/stdenv-updates/; revision=13605
implements the host support for virtio devices in Linux >= 2.6.25
guests. Network performance shows a huge improvement with
virtio_net, which should be good for the build farm (which uses
Samba/CIFS to mount the file system of the host).
* Kernel headers for 2.6.26-rc5 added to build KVM 69. Also added the
2.6.25 headers, which turned out to be too old for KVM 69.
svn path=/nixpkgs/trunk/; revision=11985
* Updated the kernel headers.
* ghc: setup hooks are now generated using substituteAll.
svn path=/nixpkgs/branches/stdenv-updates-merge/; revision=10838
kernel for performance (and VT/AMD-V in the CPU), but also provides
a working QEMU for non-KVM-enabled systems.
svn path=/nixpkgs/trunk/; revision=7889
* The statically linked bootstrap tools are now automatically
reproducable, just do:
$ nix-build ./make-bootstrap-tools.nix
The resulting binaries in result/in-nixpkgs go to
stdenv/linux/bootstrap/<platform>/, and the tarballs in
result/on-server go to
https://svn.cs.uu.nl:12443/repos/trace/tarballs/trunk/stdenv-linux/<platform>/<revision>/.
These are checked out on nix.cs.uu.nl under http://.../dist/tarballs.
* The statically linked libraries all use dietlibc now (except
patchelf and glibc), so they are much smaller. This is especially
nice for the tools in the Nixpkgs tree, since it makes Nixpkgs
tarballs smaller.
* Use Binutils 2.17 and GCC 4.1.1 for the bootstrap.
* The stdenv is now based on Glibc 2.5. I hope it works ;-)
svn path=/nixpkgs/trunk/; revision=6803
* GCC 3.4.5.
* Updated several other stdenv packages.
* Modified the builders of several packages to use the generic
builder.
svn path=/nixpkgs/trunk/; revision=4336
- disable tiger, strategoxt, they don't work and give errors
- ftp.nl.kernel.org seems to have some problems, replaced with ftp.de.kernel.org
should be put back eventually
svn path=/nixpkgs/trunk/; revision=1215
* 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
builders for typical Autoconf-style to be much shorten, e.g.,
. $stdenv/setup
genericBuild
The generic builder does lots of stuff automatically:
- Unpacks source archives specified by $src or $srcs (it knows about
gzip, bzip2, tar, zip, and unpacked source trees).
- Determines the source tree.
- Applies patches specified by $patches.
- Fixes libtool not to search for libraries in /lib etc.
- Runs `configure'.
- Runs `make'.
- Runs `make install'.
- Strips debug information from static libraries.
- Writes nested log information (in the format accepted by
`log2xml').
There are also lots of hooks and variables to customise the generic
builder. See `stdenv/generic/docs.txt'.
* Adapted the base packages (i.e., the ones used by stdenv) to use the
generic builder.
* We now use `curl' instead of `wget' to download files in `fetchurl'.
* Neither `curl' nor `wget' are part of stdenv. We shouldn't
encourage people to download stuff in builders (impure!).
* Updated some packages.
* `buildinputs' is now `buildInputs' (but the old name also works).
* `findInputs' in the setup script now prevents inputs from being
processed multiple times (which could happen, e.g., if an input was
a propagated input of several other inputs; this caused the size
variables like $PATH to blow up exponentially in the worst case).
* Patched GNU Make to write nested log information in the format
accepted by `log2xml'. Also, prior to writing the build command,
Make now writes a line `building X' to indicate what is being
built. This is unfortunately often obscured by the gigantic tool
invocations in many Makefiles. The actual build commands are marked
`unimportant' so that they don't clutter pages generated by
`log2html'.
svn path=/nixpkgs/trunk/; revision=845
