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
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
`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
Redland's use of the pre-processor symbol SQLITE_API collides with a
symbol of the same name in sqlite 3.6.19. Patching the source code to
use REDLAND_SQLITE_API instead works around the problem.
svn path=/nixpkgs/trunk/; revision=18100
Sqlite has a build mode called "amalgamation" that gathers all 90+ source code
files into a single sqlite3.c file before compiling the library. Building
sqlite this way reportedly gives a 5-10% performance gain because the compiler
can perform more sophisticated optimizations.
svn path=/nixpkgs/trunk/; revision=18092
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
propagatedBuildInputs, because those inputs are required by the *.pc
or *.la files of the package:
- If a *.pc file references a non-propagated input, then Gnome
packages have the bad tendency to silently ignore this problem in
configure scripts - the failure of a command like `pkg-config
--cflags foo' will be ignored if a dependency of foo.pc is
missing, so no flags will be added, and the build will fail later
on a missing header or library.
- If a *.la file references a non-propagated input, the build will
also fail, because Libtool will add library dependencies that it
cannot find. (Arguably *.la files should never reference packages
that aren't in the corresponding *.pc file, but they do it
anyway).
By setting the propagatedBuildInputs properly, it should be possible
to get rid of all the NIX_CFLAGS_COMPILE / NIX_LDFLAGS hacks in the
Gnome expressions.
svn path=/nixpkgs/branches/xorg-7.5/; revision=18084
configuration directory so that users on other distributions don't
need to set $FONTCONFIG_FILE (NIXPKGS-29). Also use
/var/cache/fontconfig for the cache to prevent programs run by root
from writing into the Nix store.
svn path=/nixpkgs/branches/xorg-7.5/; revision=18021
patent-encumbered hinting and sub-pixel rendering. It's disabled by
default. (Or should it be enabled by default?)
svn path=/nixpkgs/branches/xorg-7.5/; revision=18019
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
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
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
They removed the usual tagged library names in 1.40 under the layout
"system", but they introduced a new layout "tagged". The "tagged" layout
is needed when we want more than one 'style' of the libraries at once(debug,release, ...
svn path=/nixpkgs/trunk/; revision=17585
* 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
$out/share/PolicyKit/policy - otherwise we can't let PolicyKit find
the policies of other packages (such as HAL).
svn path=/nixpkgs/trunk/; revision=17438
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
