From: Scott M. <us...@ar...> - 2008-06-07 03:24:26
|
Greg Chicares wrote: > 'tb' sets a one-time-only breakpoint. Did you intend > 'bt' instead, to print a backtrace? Well that was dopey, wasn't it? Sorry. Here's the traceback. (I'll put an unwrapped version at http://www.aristeia.com/Personal/traceback.txt .) #0 0x004123b0 in abort () #1 0x0041045c in make_temp_file (suffix=0x3dce98 ".s") at ../../gcc-3.4.5-20060117-3/libiberty/make-temp-file.c:174 #2 0x004099c6 in do_spec_1 (spec=0x3dce28 "-o %|.s |\n as %(asm_options) %m.s %A", inswitch=0, soft_matched_part=0x0) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:4773 #3 0x0040b507 in process_brace_body (p=0x3dac22 "}", atom=0x3dabfb "S:-o %|.s |\n as %(asm_options) %m.s %A }", end_atom=0x3dabfc ":-o %|.s |\n as %(asm_options) %m.s %A }", starred=0, matched=1) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5647 #4 0x0040b186 in handle_braces (p=0x3dabfc ":-o %|.s |\n as %(asm_options) %m.s %A }") at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5565 #5 0x0040a5df in do_spec_1 (spec=0x3dabf8 "%{!S:-o %|.s |\n as %(asm_options) %m.s %A }", inswitch=0, soft_matched_part=0x0) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5051 #6 0x0040a8a8 in do_spec_1 (spec=0x3dce00 "%(invoke_as)", inswitch=0, soft_matched_part=0x0) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5150 #7 0x0040b507 in process_brace_body (p=0x3dc8e6 "}", atom=0x3dc8cd "fsyntax-only:%(invoke_as)}", end_atom=0x3dc8d9 ":%(invoke_as)}", starred=0, matched=1) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5647 #8 0x0040b186 in handle_braces (p=0x3dc8d9 ":%(invoke_as)}") at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5565 #9 0x0040a5df in do_spec_1 ( spec=0x3dc730 " %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%b.i} %{!"..., inswitch=0, soft_matched_part=0x0) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5051 #10 0x0040b507 in process_brace_body (p=0x3dc715 "}", atom=0x3dc55b "MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%b.i} "..., end_atom=0x3dc55d ": %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%b.i} %{"..., starred=0, matched=1) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5647 #11 0x0040b186 in handle_braces ( p=0x3dc55d ": %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%b.i} %{"...) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5565 #12 0x0040a5df in do_spec_1 ( spec=0x3dc558 "%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%b."..., inswitch=0, soft_matched_part=0x0) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5051 #13 0x0040b507 in process_brace_body (p=0x3dc53b "}", atom=0x3dc37b "M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%"..., end_atom=0x3dc37c ":%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%b"..., starred=0, matched=1) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5647 #14 0x0040b186 in handle_braces ( p=0x3dc37c ":%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temps:%b"...) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5565 #15 0x0040a5df in do_spec_1 ( spec=0x3dc378 "%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-temp"..., inswitch=0, soft_matched_part=0x0) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5051 #16 0x0040b507 in process_brace_body (p=0x414d94 "}", atom=0x414bce "E:%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-te"..., end_atom=0x414bcf ":%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-tem"..., starred=0, matched=1) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5647 #17 0x0040b186 in handle_braces ( p=0x414bcf ":%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|traditional-cpp|no-integrated-cpp:%(trad_capable_cpp) \t\t%(cpp_options) -o %{save-tem"...) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5565 #18 0x0040a5df in do_spec_1 ( spec=0x414b84 "%{E|M|MM:%(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)} %{!E:%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|tradition"..., inswitch=0, soft_matched_part=0x0) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:5051 #19 0x0040845c in do_spec_2 ( spec=0x414b84 "%{E|M|MM:%(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)} %{!E:%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|tradition"...) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:4232 #20 0x0040839f in do_spec ( spec=0x414b84 "%{E|M|MM:%(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)} %{!E:%{!M:%{!MM: %{traditional|ftraditional:%eGNU C no longer supports -traditional without -E}\t %{save-temps|tradition"...) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:4200 #21 0x0040d24d in main (argc=3, argv=0x3d2488) at ../../gcc-3.4.5-20060117-3/gcc/gcc.c:6384 (gdb) |
From: John E. / T. <td...@td...> - 2008-06-07 03:45:04
|
Scott Meyers wrote: > Here's the traceback. (I'll put an > unwrapped version at http://www.aristeia.com/Personal/traceback.txt .) > Perfect! Just what we needed. Next, if you wouldn't mind: (gdb) break mkstemps.c:129 (gdb) run -v hello.c [ It should break on the breakpoint you just set ] (gdb) print fd Thanks, John E. |
From: John E. / T. <td...@td...> - 2008-06-07 04:41:21
|
Scott Meyers wrote: > (gdb) break mkstemps.c:129 > Breakpoint 1 at 0x4118d0: file ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c, > line 129. > (gdb) run -v hello.c > Starting program: d:\apps\MinGW\bin\gcc.exe -v hello.c > [New thread 5768.0x10e0] > Reading specs from d:/apps/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs > Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld > --with-gnu-as --host=mingw32 --target > mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java > --disable-win32-registry --disabl > jlj-exceptions --enable-libgcj --disable-java-awt --without-x > --enable-java-gc=boehm --disable-libgcj-debug --ena > nable-hash-synchronization --enable-libstdcxx-debug > Thread model: win32 > gcc version 3.4.5 (mingw-vista special r3) > > Breakpoint 1, mkstemps (template=0x3dced8 "\\/ccVjMyZI.s", suffix_len=2) at > ../../gcc-3.4.5-20060117-3/libiberty/ > 129 ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c: No such file or directory. > in ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c > (gdb) print fd > $1 = -1 > Okay, so far so good. Now, if you could do the exact same session again, except instead of "print fd" do: (gdb) print {int}errno Thanks, John E. |
From: Scott M. <us...@ar...> - 2008-06-07 04:54:27
|
John E. / TDM wrote: > Okay, so far so good. Now, if you could do the exact same session again, > except instead of "print fd" do: > (gdb) print {int}errno Here it is. I made a couple of minor changes "that couldn't possibly affect anything...." First, I'm just specifying gcc.exe as the executable to debug instead of using the full path to the exe. Second, I'm omitting the -v option to gcc. If you need me to go back and scrupulously repeat what I'd been doing, just give the word. > D:\Temp>gdb gcc.exe > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-mingw32"... > (gdb) break mkstemps.c:129 > Breakpoint 1 at 0x4118d0: file ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c, line 129. > (gdb) run hello.c > Starting program: D:\Apps\mingw\bin/gcc.exe hello.c > [New thread 2776.0xeec] > > Breakpoint 1, mkstemps (template=0x3dc6c8 "d:\\temp/cc1jYEhk.s", suffix_len=2) > at ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c:129 > 129 ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c: No such file or directory. > in ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c > (gdb) print {int}errno > $1 = 28075240 |
From: Scott M. <us...@ar...> - 2008-06-07 03:53:49
|
John E. / TDM wrote: > Perfect! Just what we needed. Next, if you wouldn't mind: (gdb) break mkstemps.c:129 Breakpoint 1 at 0x4118d0: file ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c, line 129. (gdb) run -v hello.c Starting program: d:\apps\MinGW\bin\gcc.exe -v hello.c [New thread 5768.0x10e0] Reading specs from d:/apps/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disabl jlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --ena nable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw-vista special r3) Breakpoint 1, mkstemps (template=0x3dced8 "\\/ccVjMyZI.s", suffix_len=2) at ../../gcc-3.4.5-20060117-3/libiberty/ 129 ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c: No such file or directory. in ../../gcc-3.4.5-20060117-3/libiberty/mkstemps.c (gdb) print fd $1 = -1 If you'd like to reduce the latency of this debugging session, I'm happy to set up a session with one of those screen-sharing services so that you can see what happens live. (We'll have to use phone or chat for you to tell me what commands to issue, because, while I'm sure everybody here is perfectly trustworthy, I still prefer to be the one talking to my machine.) Send me mail at sm...@ar... if you're interested. Or we can continue this way, that's fine, too. Scott |
From: Brian D. <br...@de...> - 2008-06-04 20:38:47
|
Scott Meyers wrote: > No, this succeeds: > > D:\Temp>d:/apps/mingw/bin/../libexec/gcc/mingw32/3.4.5/cc1.exe -E -quiet -v > -iprefix d:\apps\mingw\bin\../lib/gcc/mingw32/3.4.5/ hello.c But you said previously that gcc -E doesn't produce an error, so this is meaningless. You need to run the invocation of cc1 that corresponds to the command that does fail. Note the -### option is useful here. Brian |
From: Scott M. <us...@ar...> - 2008-06-04 21:35:35
|
Brian Dessent wrote: > But you said previously that gcc -E doesn't produce an error, so this is > meaningless. You need to run the invocation of cc1 that corresponds to > the command that does fail. Note the -### option is useful here. Here's a gcc invocation that fails: > D:\Temp>d:/apps/mingw/bin/gcc -v hello.c > Reading specs from d:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/specs > Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/ > mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-s > jlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --e > nable-hash-synchronization --enable-libstdcxx-debug > Thread model: win32 > gcc version 3.4.5 (mingw-vista special r3) > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. Here's the corresponding cc1 invocation; it succeeds: > D:\Temp>d:/apps/mingw/bin/../libexec/gcc/mingw32/3.4.5/cc1.exe -v hello.c > ignoring nonexistent directory "/mingw/include" > ignoring nonexistent directory "/mingw/include" > ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.5/include" > ignoring nonexistent directory "/mingw/mingw32/include" > ignoring nonexistent directory "/mingw/include" > #include "..." search starts here: > #include <...> search starts here: > End of search list. > main > > Execution times (seconds) > TOTAL : 0.03 Here's the gcc line with -### instead of -v: > D:\Temp>d:/apps/mingw/bin/gcc -### hello.c > Reading specs from d:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/specs > Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/ > mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-s > jlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --e > nable-hash-synchronization --enable-libstdcxx-debug > Thread model: win32 > gcc version 3.4.5 (mingw-vista special r3) > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. And here's the corresponding cc1 line (which doesn't seem to like -### at all): > D:\Temp>d:/apps/mingw/bin/../libexec/gcc/mingw32/3.4.5/cc1.exe -### hello.c > cc1.exe: error: unrecognized command line option "-###" > > Execution times (seconds) > TOTAL : 0.00 I don't understand the relationship between gcc and cc1, so I can't really improvise; all I can do is provide the results of the suggestions that are made here (for which I am grateful). Scott |
From: Brian D. <br...@de...> - 2008-06-04 22:09:05
|
Scott Meyers wrote: > Here's the gcc line with -### instead of -v: > > > D:\Temp>d:/apps/mingw/bin/gcc -### hello.c > > Reading specs from d:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/specs > > Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/ > > mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-s > > jlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --e > > nable-hash-synchronization --enable-libstdcxx-debug > > Thread model: win32 > > gcc version 3.4.5 (mingw-vista special r3) > > > > This application has requested the Runtime to terminate it in an unusual way. > > Please contact the application's support team for more information. This is unintentionally interesting because it seems that the error is therefore caused by the driver and not cc1. The whole point of -### is to tell the driver to print the subcommands that it would have run, but not actually run them. If gcc -### faults then it rules out all the subcommands from consideration. > And here's the corresponding cc1 line (which doesn't seem to like -### at all): Of course it doesn't, it only makes sense in terms of the driver. What I intended in my previous message is that -### can be used to print the commands that the driver would run, and then run those commands individually by hand; not that you should try adding -### to the cc1 command (or composing cc1 commands by hand for that matter.) > I don't understand the relationship between gcc and cc1, so I can't really > improvise; all I can do is provide the results of the suggestions that are made > here (for which I am grateful). gcc is a driver. It doesn't actually do any real work itself, but rather invokes a variety of subcommands (e.g. cc1, cc1plus, f951, as, collect2) in various ways with various command options added or changed to maintain the illusion that there is this one mythical program that compiles, assembles, and links a program when there is not. Brian |
From: Scott M. <us...@ar...> - 2008-06-07 22:49:41
|
Brian Dessent wrote: > This is unintentionally interesting because it seems that the error is > therefore caused by the driver and not cc1. The whole point of -### is > to tell the driver to print the subcommands that it would have run, but > not actually run them. If gcc -### faults then it rules out all the > subcommands from consideration. Given that we now seem to believe is that the problem I was having was that gcc was failing when it tried to open a temporary output file, doesn't it seem somewhat odd that gcc would try to open such a file with the -### option? In this case, it turned out to be convenient, but if gcc won't actually produce any output (except to stdout), should it be trying to create temporary files? Scott |
From: Aaron W. L. <aar...@aa...> - 2008-06-05 01:36:12
|
Scott Meyers wrote: > Here's the corresponding cc1 invocation; it succeeds: You should be completely sure its succeeding, by checking the exit value with something like 'echo $?' (which should yield 0). If it really is, the driver is crashing, and you should debug it directly with gdb (or whatever you have available). As before, without symbols, we won't be able to see the good stuff, but at least we can confirm its crashing. By the way, the way this works is gcc.exe calls cc1.exe to compile (including preprocessing), then gcc.exe calls as.exe (part of binutils) to assemble, then gcc.exe calls collect2.exe, and collect2.exe will call the linker ld.exe (also part of binutils). Incidentally, gcc.exe crashes after cc1.exe are pretty rare, but that appears to be what this is. |
From: JonY <10...@gm...> - 2008-06-06 03:11:03
|
Scott Meyers wrote: > Aaron W. LaFramboise wrote: >> Scott Meyers wrote: >> >>> Here's the corresponding cc1 invocation; it succeeds: >> You should be completely sure its succeeding, by checking the exit value >> with something like 'echo $?' (which should yield 0). > > I'm running a Windows command shell, so $? isn't available to me, and I don't > know the Windows equivalent. But gdb seems to think that gcc fails and cc1 > succeeds: > >> D:\Temp>gdb d:\apps\MinGW\bin\gcc.exe >> GNU gdb 5.2.1 >> Copyright 2002 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)... >> (gdb) run -v hello.c >> Starting program: d:\apps\MinGW\bin\gcc.exe -v hello.c >> >> Program exited with code 03. >> (gdb) q >> >> D:\Temp>gdb d:\apps\MinGW\libexec\gcc\mingw32\3.4.5\cc1.exe >> GNU gdb 5.2.1 >> Copyright 2002 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)... >> (gdb) run -v hello.c >> Starting program: d:\apps\MinGW\libexec\gcc\mingw32\3.4.5\cc1.exe -v hello.c >> >> Program exited normally. >> (gdb) q > > Scott > > GDB 5.2.1 is rather ancient, can you try using GDB 6.8? It might help. It is found on the MinGW sf downloads. |
From: Tuomo L. <dj...@ik...> - 2008-06-06 17:56:24
|
Scott Meyers wrote: > Aaron W. LaFramboise wrote: >> Scott Meyers wrote: >>> Here's the corresponding cc1 invocation; it succeeds: >> You should be completely sure its succeeding, by checking the exit value >> with something like 'echo $?' (which should yield 0). > > I'm running a Windows command shell, so $? isn't available to me, and I don't > know the Windows equivalent. But gdb seems to think that gcc fails and cc1 > succeeds: That would be %errorlevel%. --- C:\>fsd 'fsd' is not recognized as an internal or external command, operable program or batch file. C:\>echo %errorlevel% 9009 C:\>less dfghs dfghs: No such file or directory C:\>echo %errorlevel% 1 C:\>less Missing filename ("less --help" for help) C:\>echo %errorlevel% 0 --- -- Tuomo ... Cheer up, the worst is yet to come |
From: Scott M. <us...@ar...> - 2008-06-06 22:38:15
|
Tuomo Latto wrote: > That would be %errorlevel%. Good to know, thanks. Scott |
From: Scott M. <us...@ar...> - 2008-06-06 02:58:16
|
Aaron W. LaFramboise wrote: > Scott Meyers wrote: > >> Here's the corresponding cc1 invocation; it succeeds: > > You should be completely sure its succeeding, by checking the exit value > with something like 'echo $?' (which should yield 0). I'm running a Windows command shell, so $? isn't available to me, and I don't know the Windows equivalent. But gdb seems to think that gcc fails and cc1 succeeds: > D:\Temp>gdb d:\apps\MinGW\bin\gcc.exe > GNU gdb 5.2.1 > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)... > (gdb) run -v hello.c > Starting program: d:\apps\MinGW\bin\gcc.exe -v hello.c > > Program exited with code 03. > (gdb) q > > D:\Temp>gdb d:\apps\MinGW\libexec\gcc\mingw32\3.4.5\cc1.exe > GNU gdb 5.2.1 > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)... > (gdb) run -v hello.c > Starting program: d:\apps\MinGW\libexec\gcc\mingw32\3.4.5\cc1.exe -v hello.c > > Program exited normally. > (gdb) q Scott |
From: Scott M. <us...@ar...> - 2008-06-06 03:49:48
|
JonY wrote: > GDB 5.2.1 is rather ancient, can you try using GDB 6.8? It might help. > It is found on the MinGW sf downloads. Right, I saw that and for some reason thought I'd have to build it, so I got lazy and took the "current" version. Silly me. The results with gdb 6.8 are the same: > D:\Temp>gdb d:\apps\MinGW\bin\gcc.exe > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-mingw32"... > (gdb) run -v hello.c > Starting program: d:\apps\MinGW\bin\gcc.exe -v hello.c > [New thread 4820.0x13a0] > Reading specs from d:/apps/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs > Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/ > mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-s > jlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --e > nable-hash-synchronization --enable-libstdcxx-debug > Thread model: win32 > gcc version 3.4.5 (mingw-vista special r3) > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. > > Program exited with code 03. > (gdb) tb > No default breakpoint address now. > (gdb) q > > D:\Temp>gdb d:\apps\MinGW\libexec\gcc\mingw32\3.4.5\cc1.exe > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-mingw32"... > (no debugging symbols found) > (gdb) run -v hello.c > Starting program: d:\apps\MinGW\libexec\gcc\mingw32\3.4.5\cc1.exe -v hello.c > [New thread 5488.0x11ec] > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > ignoring nonexistent directory "/mingw/include" > ignoring nonexistent directory "/mingw/include" > ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.5/include" > ignoring nonexistent directory "/mingw/mingw32/include" > ignoring nonexistent directory "/mingw/include" > #include "..." search starts here: > #include <...> search starts here: > End of search list. > main > > Execution times (seconds) > global alloc : 0.02 (52%) usr > TOTAL : 0.03 > Program exited normally. > (gdb) q Scott |
From: JonY <10...@gm...> - 2008-06-06 04:35:23
|
Scott Meyers wrote: > JonY wrote: >> GDB 5.2.1 is rather ancient, can you try using GDB 6.8? It might help. >> It is found on the MinGW sf downloads. > > Right, I saw that and for some reason thought I'd have to build it, so I got > lazy and took the "current" version. Silly me. The results with gdb 6.8 are > the same: > >> D:\Temp>gdb d:\apps\MinGW\bin\gcc.exe >> GNU gdb 6.8 >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later<http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i686-pc-mingw32"... >> (gdb) run -v hello.c >> Starting program: d:\apps\MinGW\bin\gcc.exe -v hello.c >> [New thread 4820.0x13a0] >> Reading specs from d:/apps/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs >> Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/ >> mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-s >> jlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --e >> nable-hash-synchronization --enable-libstdcxx-debug >> Thread model: win32 >> gcc version 3.4.5 (mingw-vista special r3) >> >> This application has requested the Runtime to terminate it in an unusual way. >> Please contact the application's support team for more information. >> >> Program exited with code 03. >> (gdb) tb >> No default breakpoint address now. >> (gdb) q >> Hi, looks like gdb didn't catch the crash. Try using 3.4.5 r2 or r1 if its not a problem. That will confirm if the issue is specific to r3. |
From: Marty L. <le...@ro...> - 2008-06-06 23:36:44
|
Hi Scott, I've been watching this discussion... I've used mingw (not recently) -- but as "gcc -mno-cygwin" on a cygwin system... I think I figured out how to compile with command.com driving mingw... (I built a number of examples from petzold -- along with vlc). IMHO this woud be a good way to proceed -- get something that works, change conditions, and figure out why it isn't working..(or if it doesn't work from the start, something is wrong). marty Scott Meyers <us...@ar...> writes on Thu, 05 Jun 2008 19:32:49 MST > John E. / TDM wrote: > > Judging by the error you're getting, I'm not sure we'll be able to get > > anything out of this, but it's worth a shot. > > This is what I get (which doesn't look very useful, alas): > > > D:\Temp>gdb d:\apps\MinGW\bin\gcc.exe > > GNU gdb 5.2.1 > > Copyright 2002 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i686-pc-mingw32"... > > (gdb) run -v hello.c > > Starting program: d:\apps\MinGW\bin\gcc.exe -v hello.c > > > > Program exited with code 03. > > (gdb) bt > > No stack. > > (gdb) q > > Here's gcc failing in the same environment (to confirm the above is relevant): > > > D:\Temp>d:\apps\MinGW\bin\gcc.exe -v hello.c > > Reading specs from d:/apps/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs > > Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --tar >get=mingw32 --prefix=/ > > mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada, objc,java --disable-win32-registry --dis >able-shared --enable-s > > jlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug -- >enable-interpreter --e > > nable-hash-synchronization --enable-libstdcxx-debug > > Thread model: win32 > > gcc version 3.4.5 (mingw-vista special r3) > > > > This application has requested the Runtime to terminate it in an unusual way. > > Please contact the application's support team for more information. > > For both of the above, PATH was set as follows: > > PATH=d:\apps\mingw\bin > > > Presumably, MinGW works for hoards of people, so there must be something, er, > special about my system that leads to it failing for me. Does anybody have any > idea what kind of specialness I might have? I'm running XP/SP2 on a Lenovo > laptop (Z61T) with 2GB RAM. I confess to having a bad habit of installing > updates when Microsoft or Lenovo tell me to. Looking in the Windows Event Log > didn't yield anything that looked particularly interesting or relevant, but I > don't really know what to look for. > > FWIW, my ultimate goal is to install and play with the gcc 4.3 alpha. I > installed it in a different place than the standard mingw download, and it fails > in the same way as we've been discussing. It's my hope that if I can get the > release version of gcc working, the 4.3 alpha will magically start working, too. > > Continuing thanks for any help with this problem, > > Scott > > > ------------------------------------------------------------------------ - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Scott M. <us...@ar...> - 2008-06-06 23:41:35
|
Marty Leisner wrote: > I think I figured out how to compile with command.com driving mingw... The irony here is that I've installed and run mingw gcc distributions in the past without any problem. > IMHO this woud be a good way to proceed -- get something that works, > change conditions, and figure out why it isn't working..(or if it doesn't > work from the start, something is wrong). That's kind of where we are now. gcc is failing on the simplest legal C program, so we're trying to figure out what's why. Scott |
From: Marty L. <le...@ro...> - 2008-06-07 04:13:08
|
Scott Meyers <us...@ar...> writes on Fri, 06 Jun 2008 16:43:13 MST > Marty Leisner wrote: > > I think I figured out how to compile with command.com driving mingw... > > The irony here is that I've installed and run mingw gcc distributions in the > past without any problem. > > > IMHO this woud be a good way to proceed -- get something that works, > > change conditions, and figure out why it isn't working..(or if it doesn't > > work from the start, something is wrong). > > That's kind of where we are now. gcc is failing on the simplest legal C > program, so we're trying to figure out what's why. > > Scott > > Have you tried another machine? I doubt gcc would normally have problems with trivial programs -- unless something is very strange. \ marty |
From: John E. / T. <td...@td...> - 2008-06-07 23:11:28
|
Scott Meyers wrote: > Brian Dessent wrote: > >> This is unintentionally interesting because it seems that the error is >> therefore caused by the driver and not cc1. The whole point of -### is >> to tell the driver to print the subcommands that it would have run, but >> not actually run them. If gcc -### faults then it rules out all the >> subcommands from consideration. >> > > Given that we now seem to believe is that the problem I was having was that gcc > was failing when it tried to open a temporary output file, doesn't it seem > somewhat odd that gcc would try to open such a file with the -### option? In > this case, it turned out to be convenient, but if gcc won't actually produce any > output (except to stdout), should it be trying to create temporary files? > Of note, the call to make_temp_file happens during parsing of the specs file, which certainly should happen. Whether or not said parsing should necessitate creating temporary files is subject to debate, perhaps... -John E. |
From: Myles P. <smp...@gm...> - 2009-07-18 06:57:35
|
Was there ever any resolution to this problem? I'm having the same. I've installed Cygwin and MinGW using the .exe installer (all defaults chosen). I've set my path in my Cygwin environment like so: smprather ~ % echo $PATH /home/smprather/bin:/home/smprather/local/bin:/cygdrive/c/MinGW/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/c/Program Files/QuickTime/QTSystem/:/cygdrive/c/Program Files/Microsoft SQL Server/100/Tools/Binn/:/cygdrive/c/Program Files/Microsoft SQL Server/100/DTS/Binn/:/usr/bin:/usr/lib/lapack When compiling hello_world.c, I get: smprather ~ % gcc hello_world.c This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Exit 3 I have no problem compiling it with the Cygwin gcc (-mno-cygwin also works correctly). Thanks, --Myles -- View this message in context: http://www.nabble.com/Failed-Install-under-XP-tp17636207p24545233.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Myles P. <smp...@gm...> - 2009-07-18 20:25:51
|
BTW, MinGW *does* work when running from a Windows cmd prompt. C:\>echo %PATH% c:\MinGW\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\TortoiseSVN\bin;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Micr osoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\B inn\ C:\>gcc hello_world.c C:\>a.exe Hello World! So what is it about my Cygwin environment that's preventing MinGW from working? smprather c % pwd /cygdrive/c smprather c % gcc hello_world.c This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Exit 3 smprather c % which gcc /cygdrive/c/MinGW/bin/gcc smprather c % env ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\smprather\Application Data CLASSPATH=.;C:\Program Files\Java\jre6\lib\ext\QTJava.zip CLIENTNAME=Console COMMONPROGRAMFILES=C:\Program Files\Common Files COMPUTERNAME=MYLES-DESKTOP COMSPEC=C:\WINDOWS\system32\cmd.exe FP_NO_HOST_CHECK=NO HOMEDRIVE=C: HOMEPATH=\Documents and Settings\smprather LOGONSERVER=\\MYLES-DESKTOP NUMBER_OF_PROCESSORS=2 OS=Windows_NT PATH=/home/smprather/bin:/home/smprather/local/bin:/cygdrive/c/MinGW/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/MinGW/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/c/Program Files/QuickTime/QTSystem/:/cygdrive/c/Program Files/Microsoft SQL Server/100/Tools/Binn/:/cygdrive/c/Program Files/Microsoft SQL Server/100/DTS/Binn/:/usr/bin:/usr/lib/lapack PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 6, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=0f06 PROGRAMFILES=C:\Program Files QTJAVA=C:\Program Files\Java\jre6\lib\ext\QTJava.zip SESSIONNAME=Console SYSTEMDRIVE=C: SYSTEMROOT=C:\WINDOWS USERDOMAIN=MYLES-DESKTOP USERNAME=smprather USERPROFILE=C:\Documents and Settings\smprather VS90COMNTOOLS=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\ WINDIR=C:\WINDOWS TERM=xterm HOME=/home/smprather HOSTTYPE=i386-cygwin VENDOR=intel OSTYPE=cygwin MACHTYPE=i386 SHLVL=1 PWD=/cygdrive/c LOGNAME=smprather USER=smprather GROUP=None HOST=myles-desktop REMOTEHOST= MANPATH=:/usr/ssl/man QTDIR=/usr/lib/qt3 QMAKESPEC=/usr/lib/qt3/mkspecs/cygwin-g++ MAKE_MODE=unix SHELL=/bin/tcsh RUBYOPT=rubygems DISPLAY=:0 LS_COLORS=di=36:ex=91:so=35:bd=35:mi=35:cd=35:or=35:fi=93:ln=95:pi=35:do=35:su=35:sg=35:tw=36:ow=36 PAGER=less EDITOR=vim VISUAL=gvim Should I uninstall Visual Studio? I guess I'll try that first. Thanks, --Myles -- View this message in context: http://www.nabble.com/Failed-Install-under-XP-tp17636207p24551538.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Myles P. <smp...@gm...> - 2009-07-18 20:36:24
|
As an FAE for an EDA software company (Synopsys), I'm well aware of the mantra: "Have you tried the latest version?" So I did. And it worked! The moral to this story is that a fresh MinGW install with the Windows installer and a fresh Cygwin install, as of this date, are not compatible. Only The Shadow knows... smprather c % gcc -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32 Thread model: win32 gcc version 4.4.0 (GCC) smprather c % gcc hello_world.c smprather c % ./a.exe Hello World! -- View this message in context: http://www.nabble.com/Failed-Install-under-XP-tp17636207p24551607.html Sent from the MinGW - User mailing list archive at Nabble.com. |
From: Scott M. <us...@ar...> - 2008-06-07 04:07:26
|
> #0 0x004123b0 in abort () > #1 0x0041045c in make_temp_file (suffix=0x3dce98 ".s") at I just noticed that my environment has no variable set for where temp files should go. No TMP, no TEMP, no TMPDIR. I found that if I set any of these, the problem goes away. So it looks like gcc assumes that at least one of these is defined, and if none are, it aborts without any diagnostic. Does that correspond to what you see in the source? Scott |
From: John E. / T. <td...@td...> - 2008-06-07 04:13:01
|
Scott Meyers wrote: > I just noticed that my environment has no variable set for where temp files > should go. No TMP, no TEMP, no TMPDIR. I found that if I set any of these, the > problem goes away. So it looks like gcc assumes that at least one of these is > defined, and if none are, it aborts without any diagnostic. > > Does that correspond to what you see in the source? > Almost, and that's definitely helpful. In fact it checks if any of those are defined (along with a couple of other locations), and then falls back on the current directory. Is there any reason you know of why creating a temporary file in the working directory might fail? -John E. |