native mingw-w64 toolchains status

  • Rainer Emrich

    Rainer Emrich - 2009-07-24

    I try to summarize here the status of the mingw-w64 toolchain.

    First some information about my approach.
    I'm running a system with windows xp professional x64 edition as OS and use  mingw and msys as base system.
    The software versions I use:
    mingw-w64-runtime revision 1037
    pthreads-w32 from cvs from 21th of July with Kai's patch posted to the pthreads-w32 mailinglist applied
    binutils-cvs from 21th of July
    gcc-trunk revison 149846

    I always build the native i686-pc-mingw32 toolchain first. Using this toolchain I build the cross-configurations. Last I build the native mingw-w64 toolchains.

    Here my findings:

    1. As mentioned in several threads, the gcc driver is still broken when build with optimization.

    2. gmp is build with --disable-shared --enable-cxx and MPN_PATH=generic for the x86_64 case. In the testsuite there are two issues for i686-w64-mingw32, x86_64-w64-mingw32 and x86_64-pc-minw32:
    x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../../../../src/gmp-4.3.1/tests/misc -I../.. -I../../../../../../src/gmp-4.3.1 -I../../../../../../src/gmp-4.3.1/tests  -fexceptions  -O2 -pedantic -m64 -mtune=k8 -c ../../../../../../src/gmp-4.3.1/tests/misc/t-locale.c
    ../../../../../../src/gmp-4.3.1/tests/misc/t-locale.c:51:1: Warnung: »localeconv« ohne Attribut »dllimport« redeklariert: vorheriges »dllimport« ignoriert
    x86_64-w64-mingw32-gcc -O2 -pedantic -m64 -mtune=k8 -o t-locale.exe t-locale.o  ../../tests/.libs/libtests.a /home/rainer/software/build/x86_64-w64-mingw32/gcc-4.5.0/gmp/.libs/libgmp.a ../../.libs/libgmp.a 
    c:/mingw/cross-gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(dsnes00660.o):(.text+0x0): multiple definition of `localeconv'
    t-locale.o:t-locale.c:(.text+0x0): first defined here
    collect2: ld gab 1 als Ende-Status zurück
    make[4]: *** [t-locale.exe] Error 1


    x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../../../../src/gmp-4.3.1/tests/cxx -I../.. -I../../../../../../src/gmp-4.3.1 -I../../../../../../src/gmp-4.3.1/tests  -fexceptions  -O2 -pedantic -m64 -mtune=k8 -c ../../../../../../src/gmp-4.3.1/tests/cxx/clocale.c
    ../../../../../../src/gmp-4.3.1/tests/cxx/clocale.c:47:1: Warnung: »localeconv« ohne Attribut »dllimport« redeklariert: vorheriges »dllimport« ignoriert
    c:/mingw/cross-gcc/gcc-4.5.0/x86_64-w64-mingw32/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(dsnes00660.o):(.text+0x0): multiple definition of `localeconv'
    clocale.o:clocale.c:(.text+0x0): first defined here
    collect2: ld gab 1 als Ende-Status zurück
    make[4]: *** [t-locale.exe] Error 1

    3. mpfr is build with --disable-shared.
    There are 3 testsuite issues for i686-w64-mingw32, x86_64-w64-minw32 and x86_64-pc-mingw32:

    Error in test #8: mpfr_printf printed td characters instead of 22
    FAIL: tprintf.exe
    Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...);
    expected: "00000010610209857723, -1.2345678875e+07, 0.032258"
    got:      "00000010610209857723, -1.2345678875e+07, -0.000000"
    FAIL: tsprintf.exe
    Error in test #8: mpfr_vfprintf printed td characters instead of 22
    FAIL: tfprintf.exe

    For the native i686-w64-mingw32 compiler the is only 1 failure:
    Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...);
    expected: "00000010610209857723, -1.2345678875e+07, 0.032258"
    got:      "00000010610209857723, -1.2345678875e+07, -0.000000"
    FAIL: tsprintf.exe

    4. mpc is build with --disable-shared, testsuite is clean.

    5. mingw-w64-runtime build without issues.

    6. pthreads builds without issues

    7. binutils is build with --disable-werror. Testing on mingw is impossible.

    8. gcc is build with --disable-multilib --enable-checking=release --enable-libgomp --disable-werror BOOT_CFLAGS="-g -O0" CFLAGS="-g -O0" CXXFLAGS="-g -O0" CFLAGS_FOR_BUILD="-g -O0" CFLAGS_FOR_TARGET="-O0" CXXFLAGS_FOR_TARGET="-O0"  for all cases.
    For i686-w64-mingw32 --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ is used, the x86_64 variants are build without ada.
    Native testing is impossible.
    Here are the issues:
    A 3 stage bootstrap for i686-w64-mingw32 dies in in libgcc at stage 2.
    ../../../../../../src/gcc-4.5.0/libgcc/../gcc/unwind-c.c:29:20: schwerwiegender Fehler: unwind.h: No such file or directory
    Kompilierung beendet.
    make[3]: *** [unwind-c.o] Error 1
    make[3]: *** Waiting for unfinished jobs....
    ../../../../../../src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:31:20: schwerwiegender Fehler: unwind.h: No such file or directory
    Kompilierung beendet.
    make[3]: *** [unwind-dw2.o] Error 1
    ../../../../../../src/gcc-4.5.0/libgcc/../gcc/unwind-dw2-fde.c:33:20: schwerwiegender Fehler: unwind.h: No such file or directory
    Kompilierung beendet.
    make[3]: *** [unwind-dw2-fde.o] Error 1
    ../../../../../../src/gcc-4.5.0/libgcc/../gcc/unwind-sjlj.c:30:20: schwerwiegender Fehler: unwind.h: No such file or directory
    Kompilierung beendet.
    make[3]: *** [unwind-sjlj.o] Error 1

    Search path issue?

    For x86_64-*-mingw32 g++ is broken somehow. Here I have to dig in further.

    for both w64-mingw32 cases gcc -v -o test.exe test.c leads to:

    COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic'
    c:/mingw/gcc/gcc-4.5.0/i686-w64-mingw32/mingw/bin/../lib/gcc/i686-w64-mingw32/4.5.0/../../../../i686-w64-mingw32/bin/as.exe -v -V -o D:\DOKUME~1\rainer\LOCALS~1\Temp\ccucZoLm.o D:\DOKUME~1\rainer\LOCALS~1\Temp\ccyhnmeJ.s
    GNU assembler version 2.19.51 (i686-w64-mingw32) using BFD version (GNU Binutils)
    c:/mingw/gcc/gcc-4.5.0/i686-w64-mingw32/mingw/bin/../lib/gcc/i686-w64-mingw32/4.5.0/../../../../i686-w64-mingw32/bin/as.exe: unrecognized option `-V'

    9. Building with ppl and cloog is a second story I will come back to later on.


    • Kai Tietz

      Kai Tietz - 2009-07-24

      Thank you for this detailed list. Great job!

      The gmp issues you found are the reason, why we normally build gmp in tree (as mpfr) of gcc. But I agree those are pretty annoying.
      The testsuite failure about %Lf, is reasoned by msvcrt printf I guess, but well maybe some more detailed investigation is necessary here.
      I just checked in changes about search paths for -w64- (and -pc-) version for x64 version, so that we are using same defaults path for driver like compiler.
      Another patch I posted (but not applied now, I want that Danny can comment on it), is related to disable for multilib and x64 based version the use of dw2 unwind code.


      • Xenofears [Peter]

        I have already built a native toolchain. There is a shared toolchain, you can find it at

        There is a static toolchain there too, but it needs to be relinked with static gmp. I have already begun this, gmp is done, and you can expect it soon. I am taking a moment right now, in reaction to this post, to test and see where I am at. The problem is that you can only have static or shared gmp, not both, the headers are different, and the static libraries are still linked to shared gmp AFAIK. Expect another post soon.

        • Rainer Emrich

          Rainer Emrich - 2009-07-26

          It's possible to link completely static. You have to ensure that you have only static libraries libgmp.a libmpfr.a and libmpc.a in your library search path at build time. Then every thing is fine and no shared library is envolved. That even works for ppl and cloog with the right configure option at gcc configure time, see --with-host-libstdcxx.


      • Rainer Emrich

        Rainer Emrich - 2009-07-26

        An additional issue you know already is libtool not detecting the 64-bit import archive.
        I see that you had a discussion for a solution on the libtool mailing list quite along time ago.
        Is there any agreement how to solve the flaw?


        • Kai Tietz

          Kai Tietz - 2009-07-27

          The ball is still on libtool side IMHO. They were mentioning that they have already some patches for x64 windows, but would be unable to test them. We offered assistance here and asked for the patches to test, but well no reaction anymore. The only reply I got was from Ralf. He were talking that the have some troubles about vc integration, but well I can't see here the issue about our gcc runtime.


    • drangon zhou

      drangon zhou - 2009-07-26

      x86_64-*-mingw32-g++ is broken, it seems to be the problem of libgcc_s_sjlj-1.dll.
      I replace libgcc_s_sjlj-1.dll with a version of 2009-06-20, Then it runs ok.
      I compare the source code between 2009-06-20 to 2009-07-20, does not find any obvious
      problem. The diff is small, maybe it is worth to dig into it.

      BTW, do you modify gmp 4.3.1 ? I encounter the following problem when build gmp 4.3.1 :

      /bin/sh ../libtool --mode=compile --tag=CC ../../gmp-4.3.1/mpn/m4-ccas
      --m4="m4" /compile/mingw/cross/bin/x86_64-pc-mingw32-gcc -c
      -DHAVE_CONFIG_H -I. -I../../gmp-4.3.1/mpn -I.. -D__GMP_WITHIN_GMP
      -I../../gmp-4.3.1 -DOPERATION_`echo sqr_basecase | sed 's/_$//'`    -g
      -pipe   `test -f 'sqr_basecase.asm' || echo
      ../../gmp-4.3.1/mpn/m4-ccas --m4=m4
      /compile/mingw/cross/bin/x86_64-pc-mingw32-gcc -c -DHAVE_CONFIG_H -I.
      -I../../gmp-4.3.1/mpn -I.. -D__GMP_WITHIN_GMP -I../../gmp-4.3.1
      -DOPERATION_sqr_basecase -g -pipe sqr_basecase.asm -o sqr_basecase.o
      sqr_basecase.asm >tmp-sqr_basecase.s
      /compile/mingw/cross/bin/x86_64-pc-mingw32-gcc -c -DHAVE_CONFIG_H -I.
      -I../../gmp-4.3.1/mpn -I.. -D__GMP_WITHIN_GMP -I../../gmp-4.3.1
      -DOPERATION_sqr_basecase -g -pipe tmp-sqr_basecase.s -o sqr_basecase.o
      tmp-sqr_basecase.s: Assembler messages:
      tmp-sqr_basecase.s:124: Error: junk at end of line, first unrecognized
      character is `,'

      102     .text
      103     .align  16, 0x90
      105     .globl  ___gmpn_sqr_basecase
      107 ___gmpn_sqr_basecase:
      109     add $-48, %rsp
      110     mov %rbx, 40(%rsp)
      111     mov %rbp, 32(%rsp)
      112     mov %r12, 24(%rsp)
      113     mov %r13, 16(%rsp)
      114     mov %r14, 8(%rsp)
      116     mov %edx, %r11d
      117     mov %edx, %ecx
      118     and $3, %ecx
      119     lea 4(%rcx), %rbx
      120     cmp $4, %edx
      121     cmovg   %rbx, %rcx
      122     lea Ljmptab(%rip), %rax
      123     jmp *(%rax,%rcx,8)
      124     .section,"aw",@progbits
      125     .align  8, 0x90
      126 Ljmptab:
      127     .quad   L4
      128     .quad   L1
      129     .quad   L2
      130     .quad   L3
      131     .quad   L0m4
      132     .quad   L1m4
      133     .quad   L2m4
      134     .quad   L3m4
      135     .text
      137 L1: mov (%rsi), %rax

      • Kai Tietz

        Kai Tietz - 2009-07-26

        Yes, what we see here in assembly is elf assembly code generation. the @<...> stuff isn't supported by coff and so it is a bug. Is it by hand written assembly, or produced by gcc itself?

        No, we didn't change anything to gmp. We normally build in as generic in tree. So we can avoid this failures, as gmp isn't willing to support win32 targets proper. Don't ask me why, but this seems to be something religious


        • Rainer Emrich

          Rainer Emrich - 2009-07-26

          That's not completely right, for i686-pc-mingw32 gmp is fully supported.


          • Kai Tietz

            Kai Tietz - 2009-07-26

            You are right, the lack of support is for x64 here. We tried to get support by them, but well what came out was that, what I called a "religious" thing.



Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks