Unfortunately github's *.patch URIs contain version of git generating them,
which changes from time to time. It seems that *.diff doesn't suffer from that.
Conflicts:
pkgs/development/libraries/libarchive/default.nix
On MinGW, we're passing these programs to the configure script, but this
obviously won't work for non-autoconf-based projects.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Both branches have quite a lot in common, so it's time for a merge and
do the cleanups with respect to both implementations and also generalize
both implementations as much as possible.
This also closes#1876.
Conflicts:
pkgs/development/interpreters/lua-5/5.2.nix
pkgs/development/libraries/SDL/default.nix
pkgs/development/libraries/glew/default.nix
pkgs/top-level/all-packages.nix
First of all, this needs two upstream patches for supporting OS X 10.9,
also the cross-gcc doesn't accept -fpascal-strings, so drop the flag.
And except putting all configure flags into a multiline string, we're
now using a list, which is easier when it comes to handling optional
components.
As X isn't used on recent Mac OS X versions and Windows, I'm temporarily
using --without-x for cross-builds until we have a better way to check
for those things.
Also, don't add audiofile to buildInputs if we're cross-compiling for
MinGW.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cross builds for Darwin already include the CoreFoundation and the
libraries from XCode, so zlib already exists on that platform.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using ALSA for non-Linux systems really doesn't make much sense, so
using buildNativeInputs to ensure it won't be used for cross-builds.
Of course, if you're cross-building to Linux, the dependency won't be
used, but right now we don't have a good way to easily check whether the
cross target is Linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Might be better to have something like stdenv.isDarwinTarget, which can
be used to test for native Darwin _and_ cross-built Darwin as a target.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is just a minor fix, because when using "darwin64-x86_64-cc" for
config.openssl.system, the OpenSSL build scripts try to compile with
$prefix-cc, which is not available with the gcc-cross-wrapper.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The Makefile still contained calls to install with the -s (strip)
option, which we don't want because it uses the native strip utility and
we're going to crossStrip in fixupPhase later anyway.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The ld from cctools doesn't like the -soname argument, so let's strip it
off for now until we have a binutils <-> cctools bridge.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cross-compiling stuff against Mac OS X's CoreFoundation won't work
without ObjC support, and we don't want to compile commandline utilities
only, right?
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Let's finally hook everything into the existing cross-building
infrastructure. We're using --with-sysroot instead of --with-headers
here, because the XCode SDK contains references to /usr/lib.
I've tried to patch those references, but unfortunately (at least with
install_name_tool) it isn't possible to change those refernces in stub
dylibs.
So after bugging @tpoechtrager with annoying questions (thanks again), I
think my initial approach (patching the SDK itself and/or regenerating
the dylib stubs) was way to complicated so I ended up with this
implementation.
Also, I've added a condition to binutilsCross to use cctools if the libc
is set to libSystem. This might need some cleanups someday, mainly to
figure out how to properly bridge cctools and binutils.
So, as an example on how to cross-compile GNU Hello to Darwin, you can
use something like this:
(import <nixpkgs> {
crossSystem = {
config = "x86_64-apple-darwin13";
arch = "x86_64";
libc = "libSystem";
platform = {};
};
}).hello.crossDrv
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This really hase some nice utilities for coping with HFS+ and DMG
format. We're going to use it for extracting the xcode DMG, but it could
be used for more, even generating DMGs.
The reason I'm using the fork instead of the repository from
@planetbeing is thet the fork contains a few fixes, especially for
dealing with symlinks in HFS+ images.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Vladimír Čunát