xgcc returns status of 1 without producing an object file and declares no errors. checking for i686-pc-cygwin-gcc... /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/xgcc -B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include checking for suffix of object files... configure: error: in `/cygdrive/e/Home/cvsroot/gcc-obj/i686-pc-cygwin/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/cygdrive/e/Home/cvsroot/gcc-obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/cygdrive/e/Home/cvsroot/gcc-obj' make: *** [bootstrap] Error 2
Created attachment 19406 [details] Build log
Created attachment 19407 [details] config.log from point of error
$ report.sh uname -a CYGWIN_NT-5.1 MCKELVEY-XP 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /cygdrive/e/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --enable-checking=release --disable-win32-registry --disable-lto --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20091226 (experimental) (GCC) BUILDING: alias CONFIGURECVS='/cygdrive/e/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --enable-checking=release --disable-win32-registry --disable-lto --enable-languages=c,c++ 2>&1 | tee clog' alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g -O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap 2>&1 | tee log'
Correction, I used the cygwin compiler to bootstrap this time. $ /usr/bin/gcc.exe -v Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configure --srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe LD=/opt/gcc-tools/bin/ld.exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.3.4 20090804 (release) 1 (GCC)
What happens if you enter /cygdrive/e/Home/cvsroot/gcc-obj/libgcc, create a small conftest.c with 'int main () {}' and try to compile it with this command: /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/xgcc -B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -g -O2 conftest.c If there is still no error, can you add -v and/or run under a debugger to find out possible error causes or at least the stage at which it fails?
Here's what I get in the debugger with -v: (gdb) run -B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -v -c -g -O2 conftest.c The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /cygdrive/e/Home/cvsroot/gcc-obj/gcc/xgcc -B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -v -c -g -O2 conftest.c [New Thread 1708.0x9b4] [New Thread 1708.0xf2c] Breakpoint 1, main (argc=13, argv=0x14c9b50) at /cygdrive/e/Home/cvsroot/gcc/gcc/gcc.c:6777 6777 int linker_was_run = 0; (gdb) c Continuing. Reading specs from /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/specs COLLECT_GCC=/cygdrive/e/Home/cvsroot/gcc-obj/gcc/xgcc COLLECT_LTO_WRAPPER=/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /cygdrive/e/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --enable-checking=release --disable-win32-registry --disable-lto --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20091228 (experimental) (GCC) COLLECT_GCC_OPTIONS='-B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/' '-B/usr/local/i686-pc-cygwin/bin/' '-B/usr/local/i686-pc-cygwin/lib/' '-isystem' '/usr/local/i686-pc-cygwin/include' '-isystem' '/usr/local/i686-pc-cygwin/sys-include' '-v' '-c' '-g' '-O2' '-mtune=generic' /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/cc1.exe -quiet -v -iprefix /cygdrive/e/Home/cvsroot/gcc-obj/gcc/../lib/gcc/i686-pc-cygwin/4.5.0/ -isystem /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/include -isystem /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/include-fixed -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/../include/w32api -idirafter ../../include/w32api -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include conftest.c -quiet -dumpbase conftest.c -mtune=generic -auxbase conftest -g -O2 -version -o /cygdrive/c/DOCUME~1/Owner/LOCALS~1/Temp/ccz9XOze.s [New Thread 1708.0x658] Program exited with code 01.
OK I do not know this code. But it looks to me like it never even looks at the source file. It fails because do_spec doesn't seem to find anything to do. (gdb) print spec $12 = 0x427e24 "%{E|M|MM:%(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)} %{!E:%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E} %{!combine:\t %{save-temps*|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps*:%b.i} %{!save-temps*:%g.i} \n\t\t cc1 -fpreprocessed %{save-temps*:%b.i} %{!save-temps*:%g.i} \t\t\t%(cc1_options)}\t %{!save-temps*:%{!traditional-cpp:%{!no-integrated-cpp:\t\tcc1 %(cpp_unique_options) %(cc1_options)}}} %{!fsyntax-only:%(invoke_as)}} %{combine:\t %{save-temps*|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps*:%b.i} %{!save-temps*:%g.i}}\t %{!save-temps*:%{!traditional-cpp:%{!no-integrated-cpp:\t\tcc1 %(cpp_unique_options) %(cc1_options)}}", ' ' <repeats 16 times>, "%{!fsyntax-only:%(invoke_as)}}}}}}"
Hello James, are you still experiencing this problem? It looks to me like the xgcc driver program that you debugged was working ok, but something failed when it launched the separate cc1 process. You might need to debug that instead, but the first thing of all to do would be to run "cygcheck /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/cc1.exe" to see if you've got any kind of a missing DLL problem.
No activity since the start of the year, no response to request for information in a month. Probably was just a glitch; suspending in the absence of any further information.
OK I've been busy. I've replaced the old computer with a Windows 7 box, and reinstalled cygwin from scratch. I get the same thing: checking for i686-pc-cygwin-gcc... /cygdrive/j/Home/cvsroot/gcc-obj/./gcc/xgcc -B/cygdrive/j/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include checking for suffix of object files... configure: error: in `/cygdrive/j/Home/cvsroot/gcc-obj/i686-pc-cygwin/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/cygdrive/j/Home/cvsroot/gcc-obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/cygdrive/j/Home/cvsroot/gcc-obj' make: *** [bootstrap] Error 2 Hsre's the cygcheck, which doesn't complain: $ cygcheck gcc/cc1.exe J:\Home\cvsroot\gcc-obj\gcc\cc1.exe C:\cygwin\bin\cygcloog-0.dll C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cygwin1.dll C:\Windows\system32\ADVAPI32.DLL C:\Windows\system32\msvcrt.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\RPCRT4.dll C:\Windows\system32\SspiCli.dll C:\Windows\system32\CRYPTBASE.dll C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-LSALookup-L1-1-0.dll C:\cygwin\bin\cyggmp-3.dll C:\cygwin\bin\cygppl_c-2.dll C:\cygwin\bin\cygppl-7.dll C:\cygwin\usr\local\bin\cygstdc++-6.dll C:\cygwin\usr\local\bin\cyggcc_s-sjlj-1.dll C:\cygwin\bin\cyggmpxx-4.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygmpc-1.dll C:\cygwin\bin\cygmpfr-1.dll mckelvey@mckelvey-pc ~/cvsroot/gcc-obj $ I can try to debug cc1.exe next, I guess.
(In reply to comment #10) > Hsre's the cygcheck, which doesn't complain: Indeed. > I can try to debug cc1.exe next, I guess. That's the next thing to try. I'm just testing a build of HEAD using your formula to see if it reproduces. (BTW, it's not normal to use "make bootstrap" any more these days; bootstrapping is the default choice when you configure a native compiler anyway. I can't say if this would affect anything though, which is why I'm seeing if I can reproduce it. Another possibility is that there's a problem caused by one of the xxxFLAGS definitions, although that seems less likely.)
(In reply to comment #11) > That's the next thing to try. I'm just testing a build of HEAD using your > formula to see if it reproduces. Well, nope, that's gone way past stage 1 by now and no sign of any problems. Bizarre. Here's another possibility: (In reply to comment #10) > $ cygcheck gcc/cc1.exe [ windows dlls snipped ] > J:\Home\cvsroot\gcc-obj\gcc\cc1.exe > C:\cygwin\bin\cygcloog-0.dll > C:\cygwin\bin\cyggcc_s-1.dll > C:\cygwin\bin\cygwin1.dll > C:\cygwin\bin\cyggmp-3.dll > C:\cygwin\bin\cygppl_c-2.dll > C:\cygwin\bin\cygppl-7.dll > C:\cygwin\usr\local\bin\cygstdc++-6.dll ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > C:\cygwin\usr\local\bin\cyggcc_s-sjlj-1.dll ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > C:\cygwin\bin\cyggmpxx-4.dll > C:\cygwin\bin\cygiconv-2.dll > C:\cygwin\bin\cygmpc-1.dll > C:\cygwin\bin\cygmpfr-1.dll You seem to have some self-built dlls in your path from an earlier build? And what's all this about sjlj exceptions? You'll need to get those out of your path. I'm afraid that although we version libgcc's soname according to the EH type, we don't have similar functionality for the other shared libs yet, so Cygwin doesn't support mixing DLLs built on the two different EH models. Please check if the problem invoking cc1 goes away once you've got those DLLs out of your PATH.
OK, I deleted those odd dlls and I was able to bootstrap. I installed, and the resulting g++ errors out with a status of 1 on any input. No error messages at all. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /cygdrive/j/Home/cvsroot/gcc/configure --verbose --enable-threads --disable-nls --enable-checking=release --disable-win32-registry --disable-lto --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20100323 (experimental) (GCC) mckelvey@mckelvey-pc ~/PD $ which g++ /usr/local/bin/g++ mckelvey@mckelvey-pc ~/PD $ cygcheck /usr/local/bin/g++ C:\cygwin\usr\local\bin\g++.exe C:\cygwin\bin\cygwin1.dll C:\Windows\system32\ADVAPI32.DLL C:\Windows\system32\msvcrt.dll C:\Windows\system32\KERNELBASE.dll C:\Windows\system32\ntdll.dll C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll C:\Windows\system32\RPCRT4.dll C:\Windows\system32\SspiCli.dll C:\Windows\system32\CRYPTBASE.dll C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll C:\Windows\system32\API-MS-Win-Security-LSALookup-L1-1-0.dll What to try next?
I now see that sjlj dll is back in /usr/local/bin, along with the other one. I delete them, and the new g++ works. At least it compiles to a .o again. We'll see if my project actually runs properly. So I guess that the build and install recreates those rogue dlls.
(In reply to comment #14) > I now see that sjlj dll is back in /usr/local/bin, along with the other one. I > delete them, and the new g++ works. At least it compiles to a .o again. We'll > see if my project actually runs properly. > > So I guess that the build and install recreates those rogue dlls. > My project compiles and links, but cannot run because the DLL is missing. So the DLL must be deleted to compile. but present to run. I get the same behavior on two hosts, one running Windows 7 and the other XP. Please advise.
(In reply to comment #15) > (In reply to comment #14) > > So I guess that the build and install recreates those rogue dlls. > > > > My project compiles and links, but cannot run because the DLL is missing. So > the DLL must be deleted to compile. but present to run. Not quite, because as you've seen the compiler will still generate references to it, because the compiler is configured to use sjlj exceptions. What you actually need is to add "--disable-sjlj-exceptions" to your configure line, as seen in the system native compiler's output; then it will neither build the dll nor emit runtime references to it. After that, you will get a compiler and a shared libgcc DLL that are both compatible with the whole rest of your cygwin installation, and everything will "just work" :)
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > > So I guess that the build and install recreates those rogue dlls. > > > > > > > My project compiles and links, but cannot run because the DLL is missing. So > > the DLL must be deleted to compile. but present to run. > > Not quite, because as you've seen the compiler will still generate references > to it, because the compiler is configured to use sjlj exceptions. What you > actually need is to add "--disable-sjlj-exceptions" to your configure line, as > seen in the system native compiler's output; then it will neither build the dll > nor emit runtime references to it. After that, you will get a compiler and a > shared libgcc DLL that are both compatible with the whole rest of your cygwin > installation, and everything will "just work" :) > Yes, that did it! Thanks so much!