Community
Participate
Working Groups
There appear to be two interleaved contributions to the console output. Sometimes the tail of a long gcc comand and its (20 50 character) includes can intrerleave genuine warning messages. The interleaved result is misinterpreted so that in my casde a string of warnings became an error.
Setting target to 3.0
There doesn't seem to be enough information here to reproduce the problem. It would help to have a sample cpp file and the console error stream that it produces.
The following is some output I got today, on a completely different body of code. Admittedly this uses Altera's NIOS IDE flavouring of Eclipse 2, CDT 1, but it demonstrates exactly the same problem: make all make -C "C:/P7222/Task03DigitalRx/Willink/Workspace/control_syslib/Release" make[1]: Entering directory `/cygdrive/c/P7222/Task03DigitalRx/Willink/Workspace/control_syslib/Release' make[1]: Leaving directory `/cygdrive/c/P7222/Task03DigitalRx/Willink/Workspace/control_syslib/Release' Compiling PrimCollections.cpp... nios2-elf-gcc -xc++ -MD -c -DSYSTEM_BUS_WIDTH=32 -I.. - IC:/P7222/Task03DigitalRx/Willink/Workspace/control_syslib/Release/system_descri ption -I/cygdrive/c/altera/kits/nios2/components/altera_avalon_dma/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_dma/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_cfi_flash/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_lan91c111/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_lan91c111/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_timer/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_timer/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_jtag_uart/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_jtag_uart/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_pio/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_lcd_16207/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_! l../PrimCollections.cpp:17:32: PrimListOfRefImp.cxx: No such file or directory ../PrimCollections.cpp:18:31: PrimMapOfRefImp.cxx: No such file or directory ../PrimCollections.cpp:19:26: PrimRefImp.cxx: No such file or directory make: *** [obj/PrimCollections.o] Error 1 cd_16207/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_uart/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_uart/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_sysid/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_sysid/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_cf/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_avalon_cf/inc - I/cygdrive/c/altera/kits/nios2/components/altera_nios2/HAL/inc - I/cygdrive/c/altera/kits/nios2/components/altera_hal/HAL/inc -D__hal__ -pipe - DALT_DEBUG -O0 -g -ISources -Wall -mhw-mul -mhw-mulx -mno-hw-div -o obj/PrimCollections.o ../PrimCollections.cpp Build completed The bulk of the message is a massive echo of a nios2-elf-gcc command, possibly buffered to stdout. An error message, possibly unbuffered to stderr, appears in the the middle of it ../PrimCollections.cpp:17:32: PrimListOfRefImp.cxx: No such file or directory ../PrimCollections.cpp:18:31: PrimMapOfRefImp.cxx: No such file or directory ../PrimCollections.cpp:19:26: PrimRefImp.cxx: No such file or directory make: *** [obj/PrimCollections.o] Error 1 I'm not sure where the !<new-line> comes from before an "l" echoes and the error message continues. The interrupted -I echo should have been: I/cygdrive/c/altera/kits/nios2/components/altera_avalon_lcd_16207/inc - As a minimum this causes one line of the echo to be corrupted. It can cause the error to be misdetected, since not starting at the beginning of a line it may be missed, and consequently the next line lacks context.
At the monthly CDT conference call (June 2005). We agreed that it is invalid to have a defect assigned to a inbox owner AND set to a valid release (they should be assigned to future). The June 3/2005 deadline for triaging these defects has passes, so I am moving all the remaining ones to future.
Future means you commit to fix it in the Future. Inboxes can't make committments. Moving to '--'.
Wow! after 2 years a bureaucratic problem can be fixed. How about dealing with the significant and very reproducible and probably not very complicated coding issue.
(In reply to comment #6) > Wow! after 2 years a bureaucratic problem can be fixed. > How about dealing with the significant and very reproducible and probably not > very complicated coding issue. You mean like rewriting the indexer? Sorry, been busy. I bet if you tried this again, it might work now. The error parsers have also been rewritten in this time frame.
I've been looking at ExternalBuildRunner code recently and can see how that can happen. I also was able to simulate the problem. Contrary to OP belief this is highly obscure and complicated issue which would be difficult to reproduce without understanding intricacies of the builder code.
(In reply to comment #6) > Wow! after 2 years a bureaucratic problem can be fixed. > How about dealing with the significant and very reproducible and probably not > very complicated coding issue. Of course. You just wait and every issue gonna be solved when the time is ripe. I made an attempt to make a bit nicer and unify output of build to the console and working on that hopefully solved this issue. Now stdout and stderr are not merged before passing to ErrorParserManager but the outputs processed and buffered separately via ConsoleOutputSniffer first. Committed to master.
*** Bug 156786 has been marked as a duplicate of this bug. ***
*** Bug 236053 has been marked as a duplicate of this bug. ***
I was smoke testing the latest CDT build (#1026) and I can no longer get the include paths to populate automatically for a C/C++ exe project using the MinGW toolchain. I was able to do that with the M6a build (#1024) and it looks like the commit for bug is the only changes made that might affect scanner discovery. Would you mind taking another look Andrew? Thanks
(In reply to comment #12) I'll take a look.
You are right, scanner discovery parser got lost in DefaultRunSIProvider. Pushed fix to master, please retest again. Feel free to reopen again if any problem and thank you for the smoke test.
(In reply to comment #14) Working as expected now. Thanks for the fast turnaround Andrew.
*** cdt git genie on behalf of Andrew Gvozdev *** bug 71511: Fixed scanner discovery for minGW Trim line by scanner discovery console parsers [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=362cd87be01de89221ad5a3db9e47a23617a7a57
*** cdt git genie on behalf of Andrew Gvozdev *** bug 71511: Some house-cleaning [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=faf497d3615e8de2b2ba8e411dbf5c24f58843ef
