* xrefresh server on Linux (only paths config option is honored)
* sup can be started without hacks now :)
* rubygems update 1.3.5
* fix handling of /bin/* ruby scripts
* only recognize runtime dependencies when creating nix derivations.
Some development dependencies are no longer available.
* make ruby lib ffy compile by using NIX_POST_EXTRACT_FILES_HOOK
* update rubygems patch: Even if there is a missing dep create attr
item. Maybe this missing source can be fixed manually.
svn path=/nixpkgs/trunk/; revision=19470
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
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
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
- I still have not understood why it worked without this fix before, and I think
this has been triggered by the gcc-4.4, but I have not investigated this much. I
went with the trivial fix.
Adding a glibc-2.10.1 expression, because the glibc-2.11 still does not have
a ports release, so it cannot be used in arm. I'm using it only in native
compilation by now.
Making the default glibc to be 2.10 instead of 2.11 in armv5tel-linux.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18688
- 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
- Stating better the guile dependencies (native/host) for guile to build
- Fixing cross-linking, through --rpath-link (ld(1) explains well about it
- Made gcc call the linker and the assembler through the gcc wrapper instead of
directly. I thought this was the source of missing -rpath's, but the source
of the problem ended up being the lack of --rpath-link. But I think the
native gcc calls the wrapped ld and as, so let's do the same cross
compiling.
- Removed the binutilsCross from the glibc expressions. Now they are built
using the gcc-cross-wrapper, and they were built with the direct gcc and
binutils before this change.
- I think patchelf and strip don't break the cross-compiled binaries, so I
reallow them on cross compilation.
- I disable the checkPhase on cross compilation. This made gmp and libtool
fail when cross compiled, iirc.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18498
linking path), and with this achieved bash being cross-compilable.
I fixed the few expressions involved in bash building, so they have well stated
native and non-native inputs.
I also tried to cross-build guile, and with this I found a problem in the
actual cross-gcc: it calls the binutils ld, instead of the ld wrapper. This
way, the programs/shared_libraries don't get the proper -rpath.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18497
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
* Dropped "nolongdouble.patch". The patch no longer applies to Python 2.6, and
apparently isn't required anymore either.
* Added access to native Darwin arch utility. Python tries to run 'arch' in
the configure stage, but that binary reside in /usr/bin. To make it
available to the expression, the small wrapper darwinArchUtility is added as
a buildInput if appropriate.
* Don't pass --enable-shared. The build fails if we try to enable building of
shared libraries, apparently because some required libraries aren't linked,
i.e. the linker call isn't right.
TODO:
* Figure out how to enable shared linking.
* The resulting binary on Darwin seem to lack the binascii module.
svn path=/nixpkgs/trunk/; revision=17894
The build succeeds on i686-linux. Other platforms look good, too,
because there were hardly any changes necessary to update the expression
from 2.5.
svn path=/nixpkgs/trunk/; revision=17889
On MacOS X, we used to use the native perl interpreter from /usr/bin.
Unfortunately, that interpreter fails to build a number of packages
(Subversion, Git, etc. ...), because it assumes knowledge about the
underlying C compiler that is not valid for the compiler used by Nix.
For example, /usr/bin/perl assumes that the compiler can build binaries
for both the ppc and the x86 architecture. /usr/bin/gcc can do that, but
the gcc from Nix can't.
The solution is to compile Perl 5.10 in Nix so that the ./configure
phase can properly detect the system's capabilities. However, note that
the resulting binary is impure: it will find headers in /usr/include and
libraries in /usr/lib. In this respect, the Nix-compiled perl binary is
no different than the native one in /usr/bin -- it's just configured
more accurately.
svn path=/nixpkgs/trunk/; revision=17870
