Native x86_64-pc-mingw32 toolchain issues

2009-03-11
2013-06-06
  • Rainer Emrich

    Rainer Emrich - 2009-03-11

    Hi Kai,

    as analyzed on the mailing list and on the gcc bug-tracker, building a native x86_64-pc-mingw32 toolchain has some issues.
    The driver only works when build with -O0 at the moment. That said, there are other issues to which I will come back later. (can't build ada, libstdc++,...).

    The actual issue I post here is as follows:
    Using the native x86_64-pc-mingw32 compiler (c only) to bootstrap itself gives the following error in libcpp:
    x86_64-pc-mingw32-gcc -g -fkeep-inline-functions -Wl,--stack,8388608 -o makedepend.exe \           makedepend.o libcpp.a ../libiberty/libiberty.a \           ./../intl/libintl.a
    ./../intl/libintl.a(localename.o): In function `ua_CharUpperW':
    c:/mingw/x86_64-pc-mingw32/mingw/lib/gcc/../../x86_64-pc-mingw32/include/stralign.h:43: undefined reference to `uaw_CharUpperW'
    collect2: ld gab 1 als Ende-Status zurück
    make[3]: *** [makedepend.exe] Error 1
    make[3]: Leaving directory `/home/em/build/native-x86_64-pc-mingw32/gcc/libcpp'

    uaw_CharUpperW ist declared and referenced in include/stralign.h, but I can't find a definition in the import libraries.

    Cheers
    Rainer

     
    • Kai Tietz

      Kai Tietz - 2009-03-11

      Hallo Rainer,

      the bootstrap problem for c++ is reasoned by a donation from Corinna (cygwin). They use "Überbaum" mechanism to build. Therefore in gcc source root directory there has to be a link named "winsup" pointing on your system-root directory. Also there has to be a directory (again a symlink) in your system-root named "mingw" pointing on the directory "<sys-root>/x86_64-pc-mingw32". On NTFS you can generate those links via junction (see http://www.winhelpline.info/forum/tipps-und-tricks-windows-2000/14456-ntfs-verzeichnis-links-junctions.html\).
      The ada part is at the moment not supported, because the recent changes (or prepared changes) for libffi aren't merged on gcc's upstream. This is also the reason, why libjava isn't build, too.

      Now to your uaw_CharUpperW. Yes, this method seems not even to exists. So I assume it is a typo of initial port. I have to think about this export, where it comes from and which symbol it should refer to. The problem here is reasoned by the static inline. Normally no gnu application should reference this symbol at all.
      Could you try to replace 'static inline' by '__CRT_INLINE'

      Cheers,
      Kai

       
      • Rainer Emrich

        Rainer Emrich - 2009-03-11

        Hallo Kai,

        Thank you for the hints. I have a running native x86_64-pc-mingw32 toolchain including all languages except ada and libjava now. Build from a cross compiler.
        I had to set CFLAGS="-g -O0" for working driver.

        Rainer

         
        • Kai Tietz

          Kai Tietz - 2009-03-15

          Just for your notice: The native toolchain build (and gcc-driver) is fixed by a work-a-round. Real patch I'll sent to gcc bug tracker.
          I think it gets applied for 4.5, but maybe sooner.

          Cheers,
          Kai

           
          • Ozkan Sezer

            Ozkan Sezer - 2009-03-16

            And that real patch would be renaming _chkstk in gcc/config/i386/* to something else like _w32_chkstk or whatever?? If that is the case, why is that not acceptable for 4.4?

             
            • Kai Tietz

              Kai Tietz - 2009-03-16

              See gcc bug report http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356 for this.
              The problem here is, that also mingw32 and cygwin are affected by this change. So I am not sure if it would get accepted in Stage 4.

              Cheers,
              Kai

               
              • Ozkan Sezer

                Ozkan Sezer - 2009-03-16

                I see.  On the other hand, I don't think that I fully understand how adding aliases (the suggestion in the bugzilla) would help with the situation (this isn't my best day, though ;)

                 
                • Kai Tietz

                  Kai Tietz - 2009-03-16

                  An alias in assembly (and we talk here about an assembly file in gcc) is pretty easy.
                  E.g. I have an assembly routine called '_foo' and I want to provide a different symbol name for the same method, it is just the adding of a .global _new_foo and an new lable _new_foo.

                  .global _foo
                  _foo:
                        ret

                  would become something like this

                  .global _foo
                  .global _new_foo

                  _foo:
                  _new_foo:
                         ret

                   
                  • Ozkan Sezer

                    Ozkan Sezer - 2009-03-16

                    OK, but then we'll have both symbols and one o will still clash with the M$ lib, what am I missing here?

                     
                    • Kai Tietz

                      Kai Tietz - 2009-03-16

                      well, Danny (who is a maintainer of gcc for win32 targets like me) has objections for 32-bits. IMHO I can understand his objections, but do not agree on them, but well for 64-bit I don't want this name clash. Here for sure we won't have to life with old habbits.

                      Cheers,
                      Kai

                       
    • Rainer Emrich

      Rainer Emrich - 2009-03-11

      Hallo Kai,

      the uaw_CharUpperW issue is solved by the mentioned replace, thank you.

      Now I get different issue in configuring libgcc in stage 1:

      configure:2396: $? = 1
      configure:2415: /home/em/build/native-x86_64-pc-mingw32/gcc/./gcc/xgcc -B/home/em/build/native-x86_64-pc-mingw32/gcc/./gcc/ -L/home/em/build/native-x86_64-pc-mingw32/gcc/x86_64-pc-mingw32/winsup/mingw -L/home
      /em/build/native-x86_64-pc-mingw32/gcc/x86_64-pc-mingw32/winsup/w32api/lib -isystem /home/em/src/gcc-trunk-svn/winsup/mingw/include -isystem /home/em/src/gcc-trunk-svn/winsup/w32api/include -B/mingw/x86_64-pc
      -mingw32/mingw/x86_64-pc-mingw32/bin/ -B/mingw/x86_64-pc-mingw32/mingw/x86_64-pc-mingw32/lib/ -isystem /mingw/x86_64-pc-mingw32/mingw/x86_64-pc-mingw32/include -isystem /mingw/x86_64-pc-mingw32/mingw/x86_64-p
      c-mingw32/sys-include -o conftest -g -O2     conftest.c  >&5
      C:\msys\1.0\bin\sh.exe: *** fork: can't reserve memory for stack 0x4A0000 - 0x6A0000, Win32 error 0
            0 [main] sh" 988 sync_with_child: child 3652(0x238) died before initialization with status code 0x1
        14683 [main] sh" 988 sync_with_child: *** child state waiting for longjmp
      C:/msys/1.0/home/em/build/native-x86_64-pc-mingw32/gcc/gcc/as: fork: Resource temporarily unavailable
      configure:2418: $? = 1
      configure:2590: checking for suffix of object files
      configure:2611: /home/em/build/native-x86_64-pc-mingw32/gcc/./gcc/xgcc -B/home/em/build/native-x86_64-pc-mingw32/gcc/./gcc/ -L/home/em/build/native-x86_64-pc-mingw32/gcc/x86_64-pc-mingw32/winsup/mingw -L/home
      /em/build/native-x86_64-pc-mingw32/gcc/x86_64-pc-mingw32/winsup/w32api/lib -isystem /home/em/src/gcc-trunk-svn/winsup/mingw/include -isystem /home/em/src/gcc-trunk-svn/winsup/w32api/include -B/mingw/x86_64-pc
      -mingw32/mingw/x86_64-pc-mingw32/bin/ -B/mingw/x86_64-pc-mingw32/mingw/x86_64-pc-mingw32/lib/ -isystem /mingw/x86_64-pc-mingw32/mingw/x86_64-pc-mingw32/include -isystem /mingw/x86_64-pc-mingw32/mingw/x86_64-p
      c-mingw32/sys-include -c -g -O2    conftest.c >&5
      C:\msys\1.0\bin\sh.exe: *** fork: can't reserve memory for stack 0x4A0000 - 0x6A0000, Win32 error 0
            0 [main] sh" 3424 sync_with_child: child 3004(0x238) died before initialization with status code 0x1
        14795 [main] sh" 3424 sync_with_child: *** child state waiting for longjmp
      C:/msys/1.0/home/em/build/native-x86_64-pc-mingw32/gcc/gcc/as: fork: Resource temporarily unavailable

      Cheers,
      Rainer

       
      • Rainer Emrich

        Rainer Emrich - 2009-03-11

        I forgot to mention I'm working with msys.

        Rainer

         
        • Kai Tietz

          Kai Tietz - 2009-03-11

          Hallo Rainer,

          Good, I'll change this in our svn. Thanks for testing the suggested patch.
          Now you're running into a typical msys (cygwin) issue. You have to verify, that don't have installed any applications mentioned in the *black list* of cygwin. For some strange reasons, it dislikes some applications, which hook windows API methods. Commonly those are some virus-scanners, logitek mouse-drivers, etc. (also we know that the old version from Aladdin for hasphl dongle drivers make troubles).

          Cheers,
          Kai

           
          • Rainer Emrich

            Rainer Emrich - 2009-03-11

            Hello Kai,

            I'm not really sure, if the fork problem I faced with, is really a msys, cygwin symptom.
            The native x86_64-pc-mingw32 toolchain build with the cross-compiler is working.
            But I will check anyway.

            Rainer

             
            • Jonathan Yong

              Jonathan Yong - 2009-04-08

              Hello Rainer,

              Do also check for which version of make and msys you are using.

              There are updated msys-1.0.dll from mingw.org, perhaps you can replace yours and see if it works. The dll should be under the "Technology Preview: MSYS-1.0.11" section.

               

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

Sign up for the SourceForge newsletter:





No, thanks