ghdl-wrapper.
I made the gcc-4.3.4 expression allow the 'vhdl' language through ghdl.
The ghdl developer recommends this gcc version; maybe it would work with
gcc-4.4. If not this ghdl version, maybe next versions.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19071
Some things don't work:
- The ghdl expression (it still needs the gcc 4.3.4 src, ...)
- The gnat wrappers need to be more generic - now they work only for the
given gnatboot (taken from gentoo) and gnats installed to their $out
store path.
- Using the cloogppl and ppl. We will need our own gnatboot built with c++
libraries for that.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19060
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
flag. Note that ATerm 2.5 causes Nix to segfault, and ATerm 2.8
doesn't even build on x86_64-linux (see
http://bugzilla.sen.cwi.nl:8080/show_bug.cgi?id=1042).
svn path=/nixpkgs/branches/stdenv-updates/; revision=19020
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
