Attrnames and package names should be as close as possible to avoid confusion.
I took care not to confuse the two mpc things during the mass-replace,
so hopefully I suceeded (tarball still builds).
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>
Sometimes the build failes with:
In file included from ../../gcc-4.4.6/gcc/ada/seh_init.c:44:
../../gcc-4.4.6/gcc/system.h:418: error: conflicting types for 'strsignal'
/nix/store/6h129q168ahnl2nzw6azr239cba884ng-glibc-2.18/include/string.h:560: note: previous declaration of 'strsignal' was here
and sometimes it doesn't. Hopefully disabling parallel builds fixes
this.
http://hydra.nixos.org/build/7179481
Without it, gcc builds for softfloat, and the glibc doesn't have support for
softfloat (it ends up requiring some gnu-soft.h file). We'll have to test if
this fixes the build of gcc or not, though.
Conflicts:
pkgs/development/compilers/gcc/4.6/default.nix
pkgs/development/compilers/gcc/4.7/default.nix
The 4.7 had some weird parameters added in crossAttrs; I've removed
them, but I don't understand where they come from.
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).
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
