In order for the linker to do its job it has to match together the basic program building blocks. These are functions in a C and C++ and subroutines and functions in Fortran. Now in C and Fortran, the name of the function or subroutine is sufficient, but in C++ its not. In C++ several functions can have the same name so long as each has a unique argument list for then the compiler can match up and choose the correct one. However it must pass this information onto the linker and is does this by encoding the argument list and the function name into a single name. This process is called name mangling and produces some pretty weird names. For example, on my system, running gcc 3.0, the name
Animal::GetName() const
gets mangled into:-
_ZNK6Animal7GetNameEv
(look carefully and you can see Animal and GetName in there). If all goes well during linking then you don't need to know about name mangling at all, but if the linker finds that things are missing then you may see the mangled name. For linking purposes all these names are called symbols and, for any given file, are either defined i.e. correspond to code in the file, or undefined i.e. correspond to calls that code makes to other code. Even symbols in C and Fortran programs may be subjected to name mangling, but here its normally nothing worse than adding a trailing underscore.
nm is a useful utility to list the contents object, library and executable files, for example:-
nm Dog.o
lists all the symbols defined or undefined in Dog.o. By default they are mangled but you can demangle them by:-
nm -demangle Dog.o
Again, for my version of gcc I have to tell it the name mangling scheme:-
nm -demangle=gnu-new-abi Dog.o
You get information about lots of symbols you don't need to know about, so piping the result into grep can be handy. For example, to see what Animal code Dog requires:-
nm -demangle Dog.o | grep Animal
A new utility c++filt can also be used to demangle names. For example:-
c++filt _ZNK6Animal7GetNameEv
on my machine gives:-
Animal::GetName() const