* Use socat's "exec" and "nofork" options to reduce the number of
processes. Also, if smbd exits abnormally, exit from the smbd
restart loop.
svn path=/nixpkgs/trunk/; revision=22279
-no-kvm-irqchip flag, and on the Hydra machines only works on the
rather old KVM 76. So as a workaround, don't use -smb, but use
QEMU's "guestfwd" feature to forward 10.0.2.4:139 in the guest to a
Unix domain socket on the host connected to Samba.
* Use "cache=writeback" to improve performance a lot.
* Use "werror=report" to make QEMU crash instead of hang if the host
filesystem is full.
svn path=/nixpkgs/trunk/; revision=22249
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
cross-building nixpkgs implementation, were not referenced anywhere.
This new busybox builds natively, and also cross-builds with uclibc.
I updated the uclibc config with a busybox defconfig requirement (something about RPC).
I made the gcc-cross-wrapper properly set the dynamic loader to programs.
After this, 'qemu-arm' can run the dynamically linked busybox cross built for armv5tel--linux-gnueabi.
svn path=/nixpkgs/trunk/; revision=20514
I introduce the new nixpkgs parameter "platform", defaulting to "pc",
which was before defined as an attribute of nixpkgs.
I made the crossSystem nixpkgs attribute set parameter contain its own 'platform'.
This allows cross-building a kernel for a given crossSystem.platform in a non-PC
platform.
The actual native platform can be taken from stdenv.platform, and this way we also
avoid the constant passing of 'platform' to packages for platform-dependant builds
(kernel, initrd, ...).
I will update nixos accordingly to these changes, for non-PC platforms to work.
I think we are gaining on flexibility and clearness. I could cross build succesfully
an ultrasparc kernel and a mipsel kernel on PC. But since this change, I should be able
to do this also in non-PC.
Before this change, there was no possibility of distinguishing the "target platform" or
the "native build platform" when cross building, being the single "platform" attribute
always interpreted as target platform.
The platform is a quite relevant attribute set, as it determines the linuxHeaders used
(in the case, by now the only one supported, of linux targets).
The platform attributes are quite linux centric still. Let's hope for more generality to come.
svn path=/nixpkgs/trunk/; revision=20273
