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).
The gccinstall manual says that parallel building with a profiled
bootstrap is not supported. As we don't have much means of checking
if our profiled bootstrap with parallel build was good or bad, I
propose going to safe terrain.
Removing a gcc flag, --enable-version-specific-runtime-libs, that put gcc libs
in a speparate directory instead of /lib; this broke the installation of
libgcc_s.a for the case of "--enable-shared" in mingw-w64. And we already have all gccs in directories apart.
I also add the option --enable-fully-dynamic-string, which is used in the
prebuilt mingw64 toolchain; this way nixpkgs creates ABI-compatible binaries
with mingw64 upstream. (told by jon_y on irc ##mingw)
svn path=/nixpkgs/trunk/; revision=34242
shared libraries are wrong.
It should run "-lstdc++ -lsupc++" if libstdc++-6.dll is available, and instead it runs
"-lstdc++" and therefore lack symbols.
I think simply few people use shared gcc libs on mingw.
svn path=/nixpkgs/trunk/; revision=34225
ambrop7@gmail.com