Related
For some long errors, the gcc output is dense and has lots of line-wrapping etc. Especially when errors are subtle, it can take me 10-30 seconds of squinting to parse it with my eyes.
I've taken to pasting this in an open code-editor window to get some basic syntax highlighting and enable reformatting with regex's.
Has anyone invented a more automated method?
I use this script, called colorize:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
Then I just call it like this(using make or whatever build system):
make |& colorize
And I get color output similar to clang.
I've found colorgcc to be invaluable. By introducing coloring, it becomes much easier to mentally parse the text of gcc error messages, especially when templates are involved.
If your errors are template related, take a look at STLfilt:
http://www.bdsoft.com/tools/stlfilt.html
gccfilter does coloring & simplification of messages.
http://www.mixtion.org/gccfilter/
If you use GCC 4.9, you can add -fdiagnostics-color=auto as an additonal compilation flag. At some later version, the color has been enabled by default.
check diagcc out, you can get something like this:
If your gcc ≥ 4.9, you can use argument -fdiagnostics-color=always.
To answer your question 4 years later, clang should be mentioned here.
Here's my current hack, which mostly inserts newlines and indentation in strategic locations along with a little extra annotation, but does nothing to address STL verbosity.
Note that as currently implemented, this script does not return an error if the compiler returned one, so doing something like this will not work properly: (make && ./runApplication). This could surely be remedied by someone with better bash-fu.
#!/bin/bash
# SUBSTITUTION RULES:
# Note: All substitution rules must end in a semi-colon, inside of the closing quote
subColonSpace='s/: /:\n /g;'
subSrc='s/^src/\nsrc/;'
subError='s/error:/error:\n\n======================================\nERROR:/;'
subWarning='s/ *error: *\n/ERROR: /;'
subWarning='s/ *warning: *\n/WARNING: /;'
subNote='s/note:/\n NOTE:/g;'
subOpenTic='s/‘/\n ‘/g;'
subOpenParen='s/(/(\n /g; s/(\n *)/()/g;'
subCommaSpace='s/, /,\n /g;'
# Note: The order of these may matter
sedExpr="$subColonSpace $subSrc $subError $subWarning $subNote $subOpenTic
$subOpenParen $subCommaSpace"
makelogFile=makelog.tmp
make "$#" 2>&1 | sed "$sedExpr" | tee $makelogFile
if you like Ruby there is GilCC! GilCC is very easy to install (just copy it to the bin folder) and easy to use (just type GilCC instead of "gcc" or "make") and it works with GCC version. Unlike Perl based scripts GilCC has statistics such as # of warnings and error and compile time. You don't have to mess with .bash files and it is cross platform as long as you can run Ruby on your machine. Since it has the power of Ruby; you can make GilCC do different things such as trigger test automation, unit test or program external hardware after a successful build.
Here is the link to the download page: http://www.onlysolutionssoftware.com/gilcc/
Yes,I was wondering what information does the program contain regarding the compiler that compiled it.
Information like compiler name,version.This is usually mentioned in about box of help(program like Vlc) menu,but my question is does compiler write any thing to .exe.
The reason i am asking this is to get information regarding the compiler by disassembling the program in any disassembler(IDA,OLLY).
Since you specifically mentioned VLC, the player is doing it in the following way: In line 50935 (at least on my VLC source package, which is 2.1.4) in the configure script there is the following statement:
cat >>confdefs.h <<_ACEOF
#define VLC_COMPILER "`$CC -v 2>&1 | tail -n 1 | sed -e 's/ *$//'`"
_ACEOF
which as you can see updates the confdefs.h file with the version of the compiler. Indeed, if you execute the statement:
$ gcc -v 2>&1 | tail -n 1 | sed -e 's/ *$//'
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
later this confdefs.h is "injected" in config.h and the line there will be 683 (for me and my compilation only, this might be different for you but you need to look after VLC_COMPILER)
/* compiler */
#define VLC_COMPILER "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)"
And when VLC wants to print out the compiler it simply prints this string (in version.c there is the VLC_Compiler() method defined which returns this.
And to finally answer your question: I sort of remember that some (older) versions of Borland compilers (Turbo C) injected a copyright information, however I did not experience this in any recent compilers, however this does not mean that they do not. This is compiler specific, and there is nothing that makes them or stops them doing this. In the worst case you always can look at the binary via a (hex) viewer to see anything funny...
g++ sometimes produces pretty convoluted outputs. Specially when dealing with templates. Is there any tool that makes g++ output more readable? ... at least some color?
It may sound silly to ask this question here, but I've been unable to google my way out of this.
GCC as of 4.9 has colourized output ☺
Append the following to your bashrc/zshrc/whatever.
export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
If you're free to switch compiler, try clang++. It's error outputs are most of the time very clear and sometimes it will even tell you what to do to fix your error. You can find a comparison of gcc vs clang error output here: http://clang.llvm.org/diagnostics.html.
Otherwise, as noted by Matteo Italia, look to STLFilt.
For the color aspect, Edwin Buck's solution (colorgcc) is very good. You can create symlinks to it named gcc, g++, etc so that it always gets used whenever you run a compiler command (provided you setup the paths in the colorgcc script correctly). I find this especially convenient when compiling some large project from a Makefile. Helps tremendously to detect where exactly something went wrong (especially when you do parallel compilations with make -j).
There's colorgcc, a perl script which wraps the gcc (g++) output with color for easier readability.
As far as the "output" of gcc (g++) I am guessing you're not complaining about the compiled binaries :)
I improve it by using sed to color the output with this script:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
If you use gcc 4.9 or higher there are a couple built-in options:
-fmessage-length=n, which optimizes the output for lines of n characters length.
-fdiagnostics-color=always, which applies some nice colors. (Works fine on linux, not so much on msys)
For more options and exact usage heres the documentation:
https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html
When dealing with the STL1, STLFilt comes to the rescue.
On a related note, I also heard that the clang compiler produces by itself much better error messages in general.
Nitpickers' corner
Actually, not the SGI STL, but the parts of it that have been adopted in the C++ standard and are part of the standard library.
I can't answer your question directly, but note that in regards to templates if you look at the top message (the error caused by the templated) and the bottom "instantiated from here" message, it usually becomes much more clear. Ignore all the middle messages as they are probably not going to help.
There is colorgcc.
there is my personal function:
colorgcc()
{
perl -wln -M'Term::ANSIColor' -e '
m/not found$/ and print "\e[1;30m$`\e[0m", "$&", "\e[0m"
or
m/found$/ and print "\e[1;30m$`\e[0;32m", "$&", "\e[0m"
or
m/yes$/ and print "\e[1;30m$`\e[0;32m", "$&", "\e[0m"
or
m/no$/ and print "\e[1;30m$`\e[0m", "$&", "\e[0m"
or
m/ Error |error:/i and print "\e[1;91m", "$_", "\e[0m"
or
m/ Warning |warning:/i and print "\e[0;33m", "$_", "\e[0m"
or
m/nsinstall / and print "\e[0;36m", "$_", "\e[0m"
or
m/Linking |link: |\.a\b/ and print "\e[1;36m", "$_", "\e[0m"
or
m/Building|gcc|g++|\bCC\b|\bcc\b/ and print "\e[1;30m", "$_", "\e[0m"
or
print; '
}
you can use GilCC which is a Ruby tool that will convert GCC output to color in real-time. It is free and you can customize it to your preference. It is not intrusive as it does not change your gcc setup and you don't have to edit any system files such as .bash. You have to install Ruby and be able to invoke Ruby programs from the command line. Right now you have two options Perl script or GilCC and if you work with Ruby you will like GilCC.
Then whenever you call "GillCC" it will call "make" behind the scenes with your parameters such as "clean", "debug" or "release". for example if normally you call: "make debug" you should call "GilCC debug".
Almost forgot to mention that GilCC has some statistics such as # of warnings and error as well as build time. These things are handy when you are trying to improve your build.
The link to the download page is here.
I'm trying to build Amaya. When the build failed with
error: expected unqualified-id before ‘(’ token
I ran g++ with only the preprocessor (replacing the -c option with -E) on the file that failed to compile to see what was going on. This produced an 80,000 line file, showing me that 'Blue' had been replaced by (2 << 8), which clearly explained the error. If I correct this, the file compiles fine. I guess I could live with that, but I would like to find out why this is happening.
Is there any way I can track how the preprocessor is replacing a specific string, in this case 'Blue'?
================= Update ===================
Well, I found the culprit:
> headers=`g++ [omited for brevity] -M \
../../thotlib/dialogue/AmayaClassicNotebook.cpp`
> for file in $headers ; do grep -s -H Blue $file | grep "(2 << 8)";done
/usr/local/include/gc.h:#define Blue (2 << 8)
So adding #undef Blue fixed the problem. So using this combination of -M and grep seems OK but sometimes C++ preprocessor definitions can be a real forest; I was curious whether there were some better way, some clever GNU tool maybe.
I find running
g++ ... -dD -E $file > $file.ii
to be very useful in untangling preprocessing problems. From man g++:
-dD Dump all macro definitions, at the end of preprocessing,
in addition to normal output.
If nobody comes up with anything better (based on the source line info in the preprocessed file), you could use the -M option to get a list of headers included by the source file, and search those for "Blue". I expect it's possible for some kind of obfuscation to mean that this doesn't find what you're looking for, but normally you'll turn up the definition somewhere.
What's wrong with the perennial
find /src -exec grep Blue {} /dev/null ';'
That usually works for me, at least as a first cut.
For some long errors, the gcc output is dense and has lots of line-wrapping etc. Especially when errors are subtle, it can take me 10-30 seconds of squinting to parse it with my eyes.
I've taken to pasting this in an open code-editor window to get some basic syntax highlighting and enable reformatting with regex's.
Has anyone invented a more automated method?
I use this script, called colorize:
#!/bin/bash
while read x ; do echo $x ; done \
| sed -e "s/.*error:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/.*warning:.*/\x1b[1;36m&\x1b[0m/" \
-e "s/^\(.*\)\(required from\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In instantiation of\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
-e "s/^\(.*\)\(In member\)/\x1b[1;36m\1\x1b[0mnote: \2/" \
| sed -e "s/error:/\x1b[1;31m&\x1b[1;36m/" \
-e "s/warning:/\x1b[1;35m&\x1b[1;36m/" \
-e "s/note:/\x1b[1;30m&\x1b[0m/"
Then I just call it like this(using make or whatever build system):
make |& colorize
And I get color output similar to clang.
I've found colorgcc to be invaluable. By introducing coloring, it becomes much easier to mentally parse the text of gcc error messages, especially when templates are involved.
If your errors are template related, take a look at STLfilt:
http://www.bdsoft.com/tools/stlfilt.html
gccfilter does coloring & simplification of messages.
http://www.mixtion.org/gccfilter/
If you use GCC 4.9, you can add -fdiagnostics-color=auto as an additonal compilation flag. At some later version, the color has been enabled by default.
check diagcc out, you can get something like this:
If your gcc ≥ 4.9, you can use argument -fdiagnostics-color=always.
To answer your question 4 years later, clang should be mentioned here.
Here's my current hack, which mostly inserts newlines and indentation in strategic locations along with a little extra annotation, but does nothing to address STL verbosity.
Note that as currently implemented, this script does not return an error if the compiler returned one, so doing something like this will not work properly: (make && ./runApplication). This could surely be remedied by someone with better bash-fu.
#!/bin/bash
# SUBSTITUTION RULES:
# Note: All substitution rules must end in a semi-colon, inside of the closing quote
subColonSpace='s/: /:\n /g;'
subSrc='s/^src/\nsrc/;'
subError='s/error:/error:\n\n======================================\nERROR:/;'
subWarning='s/ *error: *\n/ERROR: /;'
subWarning='s/ *warning: *\n/WARNING: /;'
subNote='s/note:/\n NOTE:/g;'
subOpenTic='s/‘/\n ‘/g;'
subOpenParen='s/(/(\n /g; s/(\n *)/()/g;'
subCommaSpace='s/, /,\n /g;'
# Note: The order of these may matter
sedExpr="$subColonSpace $subSrc $subError $subWarning $subNote $subOpenTic
$subOpenParen $subCommaSpace"
makelogFile=makelog.tmp
make "$#" 2>&1 | sed "$sedExpr" | tee $makelogFile
if you like Ruby there is GilCC! GilCC is very easy to install (just copy it to the bin folder) and easy to use (just type GilCC instead of "gcc" or "make") and it works with GCC version. Unlike Perl based scripts GilCC has statistics such as # of warnings and error and compile time. You don't have to mess with .bash files and it is cross platform as long as you can run Ruby on your machine. Since it has the power of Ruby; you can make GilCC do different things such as trigger test automation, unit test or program external hardware after a successful build.
Here is the link to the download page: http://www.onlysolutionssoftware.com/gilcc/