If you look directly at gcc output, you should install ColorGCC which displays errors in red and warning in yellow.
It's the simpler case, which fortunately happens (null pointers, etc).
The solution is to use a debugger like GDB to watch variable contents.
You have several possibilities to get into the program where the segfault occurred :
ulimit -c unlimited for bash and zsh, limit coredumpsize unlimited for tcsh; the file command tells you which program created the core dump), and inspect the core dump with GDB.
Then you have to use a memory checker, such as Valgrind. The memcheck tool will tell you about all memory access errors even if they don't throw segfault.
valgrind --tool=memcheck <your-program> <args> valgrind <your-program> <args> # memcheck is the default tool
The solution is again Valgrind:
valgrind --leak-check=full <program> <args>
It is interesting to know the sooner possible about problems. You should then use the assert() macro to check all of your parameters or variables that could cause a crash or an error. When debug is not enabled, there will be no code produced and thus no overhead.
You should enable core dumps in your shell (see Segmentation Faults), so that you can watch variables content to have information about the other variables that the one which failed the assert.
If you write your own assert macro, you should call the abort() function to create the core dump file.
If you don't want to save core dumps, you can still catch the sigabrt signal, freeze the program and attach a debugger. You can even unfreeze the program with the debugger (eg by changing a variable content), and continue the program to see what happens.
strace prints a list of system calls made by the program.
Or not so classic…
error: template with C linkage
This happens when you are declaring templates inside an extern “C” environment. This usually occurs when you include a header with C++ and templates from a C header with extern “C”.