- Upgraded KDE to 4.3.4
- Upgraded KOffice to 2.1.0
- Upgraded Konversation to 1.2.1
- Upgraded kdesvn to 1.4.1
- Upgraded ktorrent to 3.3.1
svn path=/nixpkgs/trunk/; revision=18751
(dynamic libraries of ppl and cloogppl) into the package.
We need newer binutils in the bootstrap-tools for the armv5tel in order to
be able to build gcc 4.4 from them.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18747
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
when I commited it, so it has been a expression that only worked for me, I think,
because I had done the proper fetchcvs previously.
svn path=/nixpkgs/trunk/; revision=18699
- 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
this because 'ld' wants to know the path of every library involved in a dynamic
linking. I imagine that ld does not need that in native builds because it can
call the loader for it to resolve the library rpaths, but this is not the case
for cross-building.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18577
inputs did not get in)
Updating the xorg builder script to support cross building (in fact, support
for propagating the required build inputs).
svn path=/nixpkgs/branches/stdenv-updates/; revision=18569
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
eqStrict now to return false when a b have different types. Passing
string and {} to eqStrict caused coercion failures when running tests
previously
svn path=/nixpkgs/trunk/; revision=18539
- 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
on a derivation with a meta.license attribute which does not satisfy the
license predicate.
With this adapter you can abort any install which depends on software
which are not free by default. You can try it with MPlayer, because
MPlayer depends of win32codecs flagged as "unfree".
svn path=/nixpkgs/trunk/; revision=18530
its dependencies. To make it works, you need to change the default
stdenv as documented in the error message.
./maintainers/scripts/dep-licenses.sh <attribute name>
svn path=/nixpkgs/trunk/; revision=18508
buildInputs and buildNativeInputs, on pkgconfig, which now works always
as buildDrv even asking for its hostDrv.
Key string: cross_renaming
svn path=/nixpkgs/branches/stdenv-updates/; revision=18506
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
statement of the gcc-wrapper coreutils dependency on r17867.
I don't have i686-darwin to try this.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18490
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
* Cleaned up the Eclipse classic expression a bit (e.g. use
makeWrapper). Also fall back to GTK 2.16 to fix some GUI glitches.
svn path=/nixpkgs/trunk/; revision=18485
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
derivation, the "buildInputs" in every stdenv mkDerivation don't map now
directly to the environment
variable "buildInputs" in the builder, but "buildNativeInputs". So, the inputs
build by the native compiler.
When cross compiling, they will map to the environment variable "buildInputs"
(yes, now the same name), which means does to be built with the cross compiler.
I think I improved the naming of variables a bit. There was a big mess,
specially in the stdenv adapter for cross building, and also in the default
builder script.
I also tried to add proper manager of propagatedInputBuilds, these being
propagated considering the host or build origin of that input build (so, at the
end, being those propagatedInputBuilds being propagated properly to the native
or the cross compiler.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18477
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
I made the stdenvCross adapter simpler, according to Nicolas Pierron comments,
and I commented it a bit.
There are still jobs to do. At least:
- Plan for the general renaming from buildInputs to hostInputs
- We should not break merges from trunk.
- Make the generic stdenv understand about host/buildInputs, at least for
native builds, because it is used in the always-native building of
stdenvLinux. This should allow us to remove all duplications of "*NoCross" in
nixpkgs.
svn path=/nixpkgs/branches/stdenv-updates/; revision=18449
The `--depth' argument asks Git to fetch the last revisions of the given
repo on *any* branch, which is often useless.
Thanks to Lluís Battle for clarifying this.
svn path=/nixpkgs/trunk/; revision=18438
`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
