I updated gstreamer too, because this phonon was not finding a header file. As that
did not fix much the phonon build, I helped the generic builder with NIX_CFLAGS_COMPILER for
phonon to find the proper header files. Either the phonon cmake scripts don't find properly
the gstreamer plugins header file, or we install gstreamer in a strange way.
svn path=/nixpkgs/trunk/; revision=19974
I updated cmake to use CMAKE_PREFIX_PATH instead of CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH.
There were some expressions in kde that required CMAKE_PREFIX_PATH, and now they are not anymore
a special case.
I updated most kde-4.4 files to point to kde-4.4.0 sources instead of 4.3.4 .
svn path=/nixpkgs/trunk/; revision=19965
- Added SIP 4.10 required for pyqt-4.7.x
- Removed kde libs experimental, which does not exists anymore in 4.4.0
svn path=/nixpkgs/trunk/; revision=19910
2.6.28. It's rather unfortunate that the result of building apr
depends on the capabilities of the kernel on which it's built...
svn path=/nixpkgs/trunk/; revision=19903
It's not entirely clear whether BLAS is in the public domain, but according to
<87636orixx.fsf@gnu.org> Debian did classify it that way, and the license text
sure feels like the authors intend the package to be in the public domain. So
here we are.
svn path=/nixpkgs/trunk/; revision=19686
* libpng updated to 1.4.0.
* For libjpegStatic, use a stdenv adapter to build a static library.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19605
After having established the connection to the distcc server, time out after 20
minutes of inactivity -- rather than 5 minutes, which is too quick to build
large C++ files with complex template machinery.
svn path=/nixpkgs/trunk/; revision=19600
Using nix-pkgs.conf, it is possible to disable avahi, python, and all other
optional dependencies of distcc in order to generate binaries that are as small
and simple as possible. Furthermore, there is now an option for static linking.
svn path=/nixpkgs/trunk/; revision=19599
Their build system has changed, and the source tree they distribute too, so the
dependencies changed a bit.
To get meshlab working, I update lib3ds and add levmar.
svn path=/nixpkgs/trunk/; revision=19595
$out/<platform>/bin. Because the fixup phase causes those to be
replaced by identical copies, use symlinks instead of hardlinks.
This saves about 9 MB.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19549
builder.sh already sets postInstall. As a result Glibc had a
retained dependency on bootstrap-tools. Added the "rm" to
builder.sh.
* localesbuilder.sh -> locales-builder.sh.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19516
I'm attempting to build rawtherapee, but it wants the propietary library 'rawzor'.
Maybe upstream someone will allow building without it some day. Until then, no
rawtherapee.
svn path=/nixpkgs/trunk/; revision=19497
something'.
It should not link at least for '-x c-header' and '-x c++-header', and maybe
link for '-x c' or '-x c++', but we expect noone will be linking using these
later strings.
Adding opencv, which required '-x c-header' working, and that's why I have
updated gcc wrapper.
svn path=/nixpkgs/branches/stdenv-updates/; revision=19491
- Adding ghdl with gcc 4.4 (with a patch I built for it to work)
- Adding me as maintainer to both gccs and ghdl
svn path=/nixpkgs/branches/stdenv-updates/; revision=19475
* 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
a 'firefox-dnie' that will launch the firefox in the path with the proper
environment variables to allow firefox access the Spanish national id SmartCard
as a Security Device.
For the later to work cleanly, it will require the user to enable the opensc-pkcs11
module as Security Devices in firefox.
svn path=/nixpkgs/trunk/; revision=19452
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
- Adding podofo
- Adding some new python packages
- Making new pkgs attributes for python packages to build with python 2.6
- Updating some python packages expressions to allow python 2.6, and not only 2.5.
svn path=/nixpkgs/trunk/; revision=19303
The wrapper script for ghc-pkg changes the command's default behavior such that
global packages -- i.e. packages that are part of GHC itself -- are no longer
found:
$ ghc-pkg describe base
ghc-pkg: cannot find package base
This patch remedies the problem.
svn path=/nixpkgs/trunk/; revision=19256
make cabal expression add etxra library paths only if they exist.
Adding myself as maintainer so that the buildfarm builds ghc.
svn path=/nixpkgs/trunk/; revision=19198
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
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
between uclibc/glibc still.
I started the renaming from glibc to libc regarding the cross-toolchain, but I
still have to finish.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18801
I also set the 'glibcLocales' top-level attribute point to 2.11 instead of
2.10, to match that of the 'glibc' top-level attribute.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18746
used to cross-compile, because of some bug in 4.4.2 I think. This bug does not
allow building a cross-compiler without libc:
http://archives.free.net.ph/message/20091119.140407.040d3c5b.en.html
Maybe we should wait for 4.4.3 or stay with 4.4.1 cross compiling. By now I
will keep 4.3.4 on cross compilation.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18730
Fixing the glibc-2.10 expression on cross-builds (which should be ported to
the glibc-2.11 expression once we get "ports" there)
Making kde3 and cyrus-sasl use gcc-4.3, because the strictness in gcc-4.4 does
not allow them build.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18706
- 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
renaming.
I think directory renaming breaks the usual merges... because it leaves the
'to be removed' directory in the working directory still. A manual 'rm' of the
'to be removed' directory fixed the commit.
svn merge ^/nixpkgs/trunk
svn path=/nixpkgs/branches/stdenv-updates/; revision=18661
native strip. So we now distinguish dontStrip and dontCrossStrip. I updated
the expressions for glibc-2.9 and glibc-2.11 accordingly.
I could get rid of the cross-glibc depending on the cross-gcc-stage-static.
Enabling nls in the final cross-gcc.
I still have problems on wint_t/wchar_t not working on cross build. Gettext
does not build.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18562
- 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
I was trying to cross compile SDL. Many dependencies work, but I ended seeing
libX11 not ready for cross compilation. Other xorg libraries cross-compile
well. libX11 may need a small patch. The problem is the usual "configure test
cannot be run in cross compilation", so the configure script halts.
I made the pkgconfig expression always return buildDrv, as I think it rarely
will be needed as buildInput. So to avoid rewriting all its mentions to use
it as buildNativeInput, I prefered this small change.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18500
- 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
true/false, which tells whether the derivation needs itself as
buildNativeInput.
For example, in order to build cross ncurses, we need the a native build
ncurses.
(As libtool does not work in stdenv, I have not tested this change, to check
whether finally ncurses cross-build)
svn path=/nixpkgs/branches/stdenv-updates/; revision=18489
arguments for the ncurses expression.
We should find a way to express a dependency in cross compilation of the style
"cross-ncurses depends on having the native-ncurses".
svn path=/nixpkgs/branches/stdenv-updates/; revision=18479
all the naming in nixpkgs to match the new build/host cross compilation stdenv.
Nevertheless, we decided not to do the renaming, but I forgot this change in
readline until ludo told me about it.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18474
the cross compilation functionality.
- I renamed some expected stdenv.mkDerivation parameter attributes so we can
keep this branch properly updated from trunk. We agreed with Nicolas Pierron
doing a massive renaming, so all current buildInputs become hostInputs (input
as build for the host machine, in autotools terminology) , and
then buildInputs would mean "input as for the build machine".
By now, the specific "input as for the build machine" is specified through
buildNativeInputs. We should fix this in the merge to trunk.
- I made the generic stdenv understand the buildNativeInputs, otherwise if
we start changing nixpkgs expressions so they distinguish the current
buildInputs into buildInputs and buildNativeInputs, we could break even more
nixpkgs for other platforms.
- I changed the default result of mkDerivation so it becomes the derivation for
to be run in the build machine. This allows, without any special rewriting,
"fetchurl" derivations to be always results for the build machine to use
them.
- The change above implies that, for anyone wanting to cross-compile, has to
build the hostDrv of the wanted derivation. For example, after this commit,
the usual test of "nix-build -A bison.hostDrv arm.nix" works. I described
the contents of this arm.nix in r18398.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18471
`selectVersion ./foo "bar"' instead of `import ./foo/bar.nix'.
* Replaced `with args' with formal function arguments in several
packages.
* Renamed several files to `default.nix'. As a general rule, version
numbers should only be included in the filename when there is a
reason to keep multiple versions of a package in Nixpkgs.
Otherwise, it just makes it harder to update the package.
svn path=/nixpkgs/trunk/; revision=18403
needing to keep a new tree of expressions apart for the expressions to get
cross-compiled.
I changed the whole way of using cross compilation with nixpkgs, which before
was done through a simple adapter.
Now the adapter became complex, and I've tried to avoid the most obvious
recursivities. For example, the fetchurl expression should
never be cross-compiled, as the gmp, mpfr, and some others, like
some ncurses, perl, ... I made overrided copies of those necessary as
perlNoCross, ncursesNoCross, as stdenvNoCross, keeping in mind that
the stdenv (capable of cross compilation) is built upon stdenvNoCross using
an adapter.
So, to cross compile, instead of building using "nixpkgs/default.nix",
you should build with your
own "myarchiteture.nix", which should have contents like these, for example:
import /etc/nixos/nixpkgs/default.nix
{
crossSystem = {
config = "armv5tel-unknown-linux-gnueabi";
bigEndian = false;
arch = "arm";
float = "soft";
};
}
svn path=/nixpkgs/branches/stdenv-updates/; revision=18398
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
