On Sat, 2011-08-13 at 16:11 +0200, Corinna Vinschen wrote: > > BTW, for those interested, I'm already working on updating the Fedora > > Cygwin toolchain to match the recent binutils/gdb releases and add the > > --large-address-aware patch, along with restoring cygwin-gcc-java for > > F15.
FYI, this has been pushed to the servers now. > There's a small glitch in the cross toolchain: > > $ i686-pc-cygwin-gcc foo.c -o foo > $ ls foo* > foo foo.c Confirmed, and now I see that the same happens with Fedora's mingw32-gcc. > Since foo is a Cygwin executable, shouldn't gcc append .exe? This would make sense. Since mingw32-gcc does the same thing, I'll guess that the .exe magic was only implemented for a native compiler. Looking at the code, the .exe handling is added in gcc/gcc.c. There are two macros: HOST_EXECUTABLE_SUFFIX (which adds .exe to the commands it calls (cc1/as/collect2/ld), and TARGET_EXECUTABLE_SUFFIX, which is used only for and in convert_filename() to change the output filename. But the latter is only used if: /* By default there is no special suffix for target executables. */ /* FIXME: when autoconf is fixed, remove the host check - dj */ #if defined(TARGET_EXECUTABLE_SUFFIX) && defined(HOST_EXECUTABLE_SUFFIX) #define HAVE_TARGET_EXECUTABLE_SUFFIX #endif I may be new to the GCC code, but that just looks bogus. On Linux, HOST_EXECUTABLE_SUFFIX is obviously empty, but why should that control HAVE_TARGET_EXECUTABLE_SUFFIX? I've made a patch to change that, and am rebuilding cygwin-gcc with that now. If it works (and I don't see why it won't), I'll go ahead and respin releases with the patch. Dave, anything to add here? Yaakov