Even if using profiledbootstrap. This was unsafe before 4.8, and
then the documentation was not fixed on time.
The documentation got fixed here:
c763997f34
But the actual code was already fixed here:
5d2fca09d5
So this is safe both for GCC 4.8 and GCC 4.9.
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>
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>
Mingw(32) is rather poorly maintaned and has quite a lot of bugs. And
because our Windows cross builds were also poorly maintained and most of
the cross-tests were broken as well, I'm just taking this step and try
to switch to mingw-w64 for everything "cross Windows".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
Vladimír Čunát