colorgcc is supposed to colourize warnings and errors in different colours. It works if I do "unset LANG" (but of course then the messages will be in English). If I do not unset lang, both warnings and errors will be colourized as errors. I can not show the colours here, but these 2 lines get the same colour, when it should be different: videomode.c:7: error: 'NULL' undeclared (first use in this function) videomode.c:8: warning: incompatible implicit declaration of built-in function 'printf' Reproducible: Always Steps to Reproduce:
Sorry, the 2 lines I wrote in the example are in English and do get different colours. It is the localized output that gets the same color: videomode.c:7: fel: "NULL" är odeklarerad (första förekomsten i denna funktion) videomode.c:8: varning: inkompatibel implicit deklaration av inbyggd funktion "printf"
Reading code of colorgcc it seems to me that this is not a bug, but a feature, which is currently absent. colorgcc parse the output and searchs for word "warning" which is absent in localized output. Personally I think that things like this, if ever necessary, should be done by gcc itself as only gcc best knows its output... But if you have patch for this issue we could consider applying it. :)
Yes, colorgcc is a horrible idea. It is just insane to try to parse localized output. Unfortunately GCC does not want to keep requests open for features that are not strictly necessary for converting source code into programs. pinska usually closes requests for nice-but-not-strictly-necessary features within half an hour. Let us see how long your feature request [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150] survives...
Perhaps colorgcc could keep a database based on language. It could be built automatically as needed. If the current language is unknown, it could do a test compile like this. echo -e "#warning Foo\n#error Bar\n\n" | gcc -o a.out -x c - <stdin>:1:2: warning: #warning Foo <stdin>:2:2: error: #error Bar It could then learn the warning/error strings for the current language and store them.
(In reply to comment #4) > Perhaps colorgcc could keep a database based on language. It could be built > automatically as needed. If the current language is unknown, it could do a test > compile like this. This is *really* something that we (Gentoo) cannot/willnot do anything about. Since upstream won't do it, then...well, we won't either. sorry.
