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
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
- 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
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
* 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
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
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
Add expression for ssreflect, an extension to the Coq Proof Assistant.
Still has some clitches (see TODO in default.nix) but is usable anyway.
svn path=/nixpkgs/trunk/; revision=18145
a symbol clash with glib 2.21. So we keep with glib 2.20.
I also changed the default wxGTK from 2.6 to 2.8, caring so no hash is changed due to
this change. Some packages using 2.6 may well build with 2.8, so we can try updating
them for another commit.
svn path=/nixpkgs/trunk/; revision=18133
The new version requires Tcl at build time in order to construct sqlite3.h,
even when the --without-tcl option is passed to configure. That feels odd
because the sqlite web site does advertise "no dependencies", but then it's
probably not a big deal either. The build of the Tcl plugin for sqlite is still
disabled, so there is no run-time dependency.
svn path=/nixpkgs/trunk/; revision=18091
http://www.psc.edu/networking/projects/hpn-ssh/
I tried to keep the openssh hash not changing, unless the user sets hpn in getConfig
style. I think that does not look as good as a patch changing the hash, but it may
annoy less. Let me know if it is not ok.
I don't think hpn should be the default, because it may have some insecurity implications
I don't know of. But I used to enable it in all my machines, and I hope to do so unless
advised otherwise.
svn path=/nixpkgs/trunk/; revision=18073
I tried their website renderer, but it did not work for me. It may be shut down,
because their last update is for 2006.
Next steps: put it into nixos, and build the renderer (java!).
svn path=/nixpkgs/trunk/; revision=18041
there seems to be a much cleaner solution than deepOverride, namely
call all-packages.nix with an appropriate packageOverrides set.)
svn path=/nixpkgs/branches/xorg-7.5/; revision=18025
development/libraries/{glib,gtk+,pango,atk,...}. Done for glib/gtk+
1.2. Also deleted some obsolete, unused versions (gtkLibs 2.10,
2.12, and 2.14).
svn path=/nixpkgs/trunk/; revision=17992
I could not easily make some bsdgames build or install. Too much patching
against the installer trying to write beyond the nix store.
svn path=/nixpkgs/trunk/; revision=17971
* 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
Updating libgpod
Making gtkpod accept 'ogg' files, and made it convert them well to mp3, if 'lame'
and oggdec is in path. It should better reference lame and libvorbis store path
files.
svn path=/nixpkgs/trunk/; revision=17888
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
buildDefs doesn't like buildInputs containing nulls.
* In all-packages.nix: xfsProgs -> xfsprogs, jfsUtils -> jfsutils to
match the upstream name.
svn path=/nixpkgs/trunk/; revision=17726
- Fixed location of the VirtualBox icon
- Removed qt3 as dependency of VirtualBox since it's obsolete since 3.0.x
svn path=/nixpkgs/trunk/; revision=17725
I had to use a newer patchelf (0.5), otherwise patchelf (0.4) died with an error at
setting the rpath for a lib.
("virtual address overrun" or something like that)
I still don't know of any stable url for a given version, so we will have this working
until they change the package file again updating.
svn path=/nixpkgs/trunk/; revision=17680
I don't know if the 'unfree' in the amr libraries will stop mplayer being built without its support. We would have to write the all-packages MPlayer expression different, in this case.
svn path=/nixpkgs/trunk/; revision=17635
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/FCC can do that, but the gcc from Nix can't.
The solution is to compile Perl 5.10 via Nix so that it can properly configure
itself. However, note that the resulting binary is impure: it will find headers
in /usr/include and libraries in /usr/lib -- something a pure perl binary
wouldn't do. In this respect our Nix-compiled perl binary is not better than
the native one from /usr/bin -- it's just more accurately configured.
svn path=/nixpkgs/trunk/; revision=17618
When building Emacs on MacOS X, the configure script believes that libXaw is
available and tries to link it (even when, in fact, libXaw is not available).
To work around that problem, we make Xaw support mandatory on MacOS X.
svn path=/nixpkgs/trunk/; revision=17610
They removed the url for that package version, I updated to the latest.
I changed the name from 'trueCrypt' to 'truecrypt'
I added an option for it not to have a gui built.
svn path=/nixpkgs/trunk/; revision=17587
The OpenSSH binaries built by the expression by default expect system-wide
configuration files in "/etc/ssh", which is a bit of an impurity (and certainly
inconsistent with the way other package handle --sysconfdir in Nix). Those who
prefer a clean installation, can now configure that directory path.
Adding the line "openssh = { etcDir = null; };" to $NIXPKGS_CONFIG configures
OpenSSH to use the default location, i.e. $out/etc. Setting that attribute to a
string will configure OpenSSH to use that concrete path instead.
svn path=/nixpkgs/trunk/; revision=17570
* Dropped classr.patch; it no longer applies to this version.
* The "configure" script has been renamed to "bootstrap.sh".
* The bootstrapping process generates no Makefile anymore; the build
expression has to call bjam directly to build the libraries.
* Perform build and install phase in one execution of bjam. This is a
lot faster, because bjam won't check the dependencies twice.
svn path=/nixpkgs/trunk/; revision=17471
configure script prints out this ominous warning:
WARNING: PolicyKit is disabled. You need to manually edit the hal.conf
file to lock down the service. Failure to do so allows any
caller to make hald do work on their behalf which may be
a huge SECURITY HOLE. I repeat: YOU NEED TO EDIT THE FILE
hal.conf to match your distro/site to avoid NASTY SECURITY HOLES.
Note that HAL only builds with the old PolicyKit (it looks for
polkit.pc). Reverted ConsoleKit to the last version that used the
old PolicyKit for this reason.
svn path=/nixpkgs/trunk/; revision=17432
a headache. "polkit" is the new, unstable release series.
"policykit" is the old series. (See
http://lists.freedesktop.org/archives/polkit-devel/2009-February/000106.html
for an "explanation" of the name change.) It seems that for HAL we
need to revert to the old "policykit", since it doesn't compile
against "polkit".
svn path=/nixpkgs/trunk/; revision=17425
