Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#81 native toolchain bug with recent snapshot

closed-fixed
nobody
None
5
2009-08-29
2009-03-02
david cournapeau
No

I used the mingw-w64 cross compiler (Linux 64 -> win64) to build a native toolchain, and I get the following error, for a hello world:

gcc hello.c
file.c: format not recognized

If I assemble manually, I can get it to work (command executed on windows 64):

gcc.exe -S hello.c
as.exe hello.s -o hello.o
gcc.exe hello.o -o hello.exe

Discussion

  • Kai Tietz
    Kai Tietz
    2009-03-04

    Well, the issue is related to windows vista and newer systems. The problem is in pex_win32.c and co. in libiberty. It seems so, that it doesn't find the application as long as the lpCurrentDirectory isn't set to the binary's path. This isn't do-able of course, because we would change here the current working directory.
    What I found so far is, that libiberty tries to invoke it just by application name, which of course fails, because the cc1.exe, cc1plus.exe, ... are in a different folder.

    Cheers,
    Kai

     
  • FWIW, I get the same problem on windows xp x64, so I don't think it is specific to Vista. It also works for gcc 4.3.3 (but then both fortran and C++ compilers are buggy, hence my quest for native 4.4-based toolchain ).

    I am also not sure it is a problem of finding the application on vista:on Vista (server 2008 more exactly), I can see through gcc -v that it tries to call something after compilation, but this something is an empty string (hence a confusing CreateProcess error in that case). Under windows x64, I get the format not recognized because the linker is not called - compiling with -c does work:

    # On windows xp x64
    gcc -c hello.c
    gcc hello.o -o hello.exe

    vs

    # in server2008
    gcc -S hello.c
    as hello.s -o hello.o
    gcc hello.o -o hello.exe

     
  • Sorry, my comment below is wrong. In both cases (windows x64 and server2008), I need to invoke the compiler, assembler and linker separately. The different underlying behavior (not calling as at all vs calling something which is not setup correctly) is different, though.

     
  • Kai Tietz
    Kai Tietz
    2009-03-10

    I tried to find the reason for this bug and it seems that it is reasoned by some mis-optimizations of gcc 4.4. I try to narrow it to which optimization pass it belongs. If the gcc driver is build with CFLAGS="-O0" everything works as expected.
    I assume it is possibly dependent to some stuff getting activated by -O1+. E.g. the overflow assumption (to be turned off by -fwarpv could be the reason (-Wstrict-overflow).

     
  • Kai Tietz
    Kai Tietz
    2009-03-12

    FYN Well, the -fwarpv doesn't help

     
  • Kai Tietz
    Kai Tietz
    2009-03-15

    This bug was reasoned by different variant of __chkstk. The MS version just probes stack, but doesn't allocate stack-space itself. The gnu variant of gcc probes and allocates stack. So by exports from the DLLs kernel32, ntoskernl, and ntdll the gcc required gnu version was replaced by the MS variants, which leads to stack corruption.
    Temporary I disabled those exports, on the long term I'll patch gcc to use different symbol names for this method, which prevents these kind of name collisions. AFAIK exists for mingw32 the same problem, when somebody tries to link vc generated libraries to gcc projects.

    Cheers,
    Kai

     
  • Kai Tietz
    Kai Tietz
    2009-03-15

    • status: open --> closed-fixed
     
    • status: closed-fixed --> open-fixed
     
  • Could you tell me which version of gcc/binutils you used ? I still get exactly the same problem (after updating my mingw checkout for the mingw runtime).

     
  • Thinking about it, I wonder how it could be a bug in the mingw. After all, I can get a working native compiler using gcc 4.3.3. Only gcc 4.4* snapshots do not work. Also, I don't see the relationship with VC libraries - I only try to run gcc, I don't link to anything related to VC compiler.

     
  • Kai Tietz
    Kai Tietz
    2009-03-16

    Just to be sure. When you installed the linux64->win64 toolchain in a seperate folder, you added the your <mingw-w64-toolchain-folder>/bin to your path?

    Cheers,
    Kai

     
  • Ozkan Sezer
    Ozkan Sezer
    2009-03-16

    Try using the mingw-w64-crt rev.680 (or later) AND re-compiling gcc against it. Rev.680 of crt doesn't expose the _chkstk symbol of M$ which clashes (and isn't compatible) with a gcc symbol.

     
  • Kai Tietz
    Kai Tietz
    2009-03-18

    • status: open-fixed --> pending-fixed
     
  • NightStrike
    NightStrike
    2009-03-18

    Rev 680 should be included starting with the March 14th toolchains in the Automated Builds section.

     
    • status: pending-fixed --> open-fixed
     
  • Ok, I can build native (gcc 4.4-based) C compiler using a cross compiler based on gcc 4.3.3 - if the cross compiler is gcc 4.4, I get the same problem as reported here. Unfortunately, gcc 4.4 seems to require some C++ features not supported by the 4.3.3 serie (inline namespace and co), so I can't build a native g++ yet.

    I will try to build a native toolchain from the official cross compilers distributed by the mingw-w64 project

     
  • Same problem with the cross toolchain distributed by mingw-w64 (I took the last one, from March 18). I guess this just shows an underlying bug in gcc 4.4 for the W64 target.

     
  • Kai Tietz
    Kai Tietz
    2009-04-19

    Hmm, well. I tried it again for 4.4 (with current 4.4 branch and head version of binutils) with our current crt. And it seems to work pretty well for me. The only reason I can see for you problem is, that in the libraries (libkernel32.a, libntdll.a) is still the symbol __chkstk symbol present. Could you verify for the cross-compiler and for the native one, that is symbol isn't present somewhere else then in libgcc.a?

    Cheers,
    Kai

     
  • Kai Tietz
    Kai Tietz
    2009-07-22

    Well, one issue is the mingw/lib64 path secified in mingw32.h. It should be always /mingw(lib as this is default path.
    But as we saw it isn't the complete reason of the driveer issue.

    If you could narrow it more close down (I assume still that it is related to __chkstk) it would be very helpful.

    Cheers,
    Kai

     
  • Rainer Emrich
    Rainer Emrich
    2009-07-23

    Well, I don't think that the mingw/lib64 path is the cause at all.
    I like to help as far as possible, but I have to sort out a few things first.
    I try to get an overall state for the complete toolchain including gmp, mpfr, mpc, ppl, cloog and binutils.
    I will come back to you later on.

    Cheers,
    Rainer

     
  • Kai Tietz
    Kai Tietz
    2009-08-14

    • status: open-fixed --> pending-fixed
     
  • Kai Tietz
    Kai Tietz
    2009-08-14

    This should be fixed by current runtime. It was reasoned by an strict aliasing issue in function fstat and stat of runtime.
    There are possibly (or even sure) other issues for native toolchain remaining, but could you please verify this fix?

    Thanks in advance,
    Kai

     
  • This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
    • status: pending-fixed --> closed-fixed