has to be "/bin/sh" - other values such as "sh" or "bash" or "$(type
-tP sh)" cause a build error:
LD .tmp_vmlinux1
/nix/store/1yv8i1m76cvwk5w5i5wrk4gj5zyfj6vh-binutils-2.19.1/bin/ld:arch/um/kernel/vmlinux.lds:1: ignoring invalid character `#' in expression
/nix/store/1yv8i1m76cvwk5w5i5wrk4gj5zyfj6vh-binutils-2.19.1/bin/ld:arch/um/kernel/vmlinux.lds:1: syntax error
collect2: ld returned 1 exit status
This is caused by Bash 4.0
(http://bugzilla.kernel.org/show_bug.cgi?id=13343).
svn path=/nixpkgs/branches/kernel-config/; revision=18941
* Move kernel patches out of all-packages.nix to
os-specific/linux/kernel/patches.nix.
* Make the kernel config available under $out/config (it's also in
$out/lib/modules/$version/build/.config, but that's kind of hard to
find).
svn path=/nixpkgs/branches/kernel-config/; revision=18937
regexp looking for such ld arguments did not work well with "--soname=xxx.so".
Now I added the condition that the argument should not start with a hyphen, for
it to be possibly considered a .so file to link with.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18919
Removing any reference to the gcc-wrapper2, as now the gcc-wrapper already conveys
the changes, I created gcc-wrapper2 in trunk for.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18913
`generate-config.pl' runs `make config' to generate a Linux kernel
configuration file. For each question (i.e. kernel configuration
option), unless an override is provided, it answers "m" if possible,
and otherwise uses the default answer (as determined by the default
config for the architecture). This is safer than allmodconfig,
which answers "y" everywhere it can't answer "m" and thus ends up
enabling a lot of experimental or debug options. (For this reason,
a configuration generated by allmodconfig must be carefully checked
with every new release to ensure that nothing dangerous is enabled.
The default config should be safer wrt new kernel releases.)
Overrides are specified in the `config' argument to generic.nix,
which is a string that contains lines such as `EXT2_FS_POSIX_ACL y'.
The script warns about ignored options, and aborts if `make config'
selects an answer inconsistent with the one in `config'. This
allows us to be sure that `make config' doesn't silently override
our configuration values (e.g., depending on other options, it will
set FB_TILEBLITTING to "y" even if we want it to be "n").
svn path=/nixpkgs/branches/kernel-config/; revision=18910
which deals only with a build time dependency. Let's better have hydra
build cscope (I set me as a maintainer), and prefer simpler expressions
to options on build-time dependencies.
svn path=/nixpkgs/trunk/; revision=18902
source regions which are substituded by the tool nix-repository-manager.
See http://github.com/MarcWeber/nix-repository-manager/raw/master/README.
sourceByName is called sourceFromHead now.
updates: MPlayerTrunk, haxe, neko, netsurf, cinelerra, ctags
cinelerra does no longer build due to Xorg update
svn path=/nixpkgs/trunk/; revision=18894
stdenv.
In this gcc-wrapper2 I made the ld-wrapper.sh to handle the linking with shared
objects through direct pass as ld command arguments of the absolute path to shared
objects, instead of using the -L/-l combinations.
cmake 'FindXXX.cmake' modules make a strong usage of the dynamic linking directly
passing the absolute path to the shared object to the linker, and as our wrapper did
not add any -rpath for those, writting the nix expressions for some cmake packages
resulted in a lot of tricks, compared to using this gcc-wrapper2.
This gcc-wrapper2/ld-wrapper.sh should become the gcc-wrapper/ld-wrapper in a
stdenv update.
I also updated some cmake expressions to use this gcc-wrapper2, and reduced its
tricks.
I also updated the cmake setup-hook for it to make cmake not touch any rpath decided
at build time, when running the 'make install' of makefiles created by cmake.
svn path=/nixpkgs/trunk/; revision=18885
the target libraries, as 4.3.4
I trigger the breaking build using uclibc, instead of glibc, and then the
mixture of CPP getting the build glibc headers, and CC getting the uclibc
headers, makes the problem evident.
In 4.3.4 it only affected libmudflap. In 4.4.2, it affects libmudflap and
libstdc++.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18850
through libtool.
I found a make variable holding flags that will not be trimmed by libtool:
FLAGS_FOR_TARGET.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18846
* xfsprogs: don't use shared libraries because libxfs.so isn't
installed for some reason, so mkfs.xfs doesn't work.
svn path=/nixpkgs/trunk/; revision=18842
coreutils 7.6, which did not build well. The newer coreutils 8.1 work perfectly,
and we don't need to rely in older versions.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18836
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
Dealt with the gcc 4.4 expression for it to work well for a native and a cross
compiler, adding a pair of patches to get the job done without much side
effects. One (libtool problems on -B) comes from the gcc 4.3 expression, while
the other fixes a bug already fixed in gcc 4.4.3.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18833
