C.3. Understanding the Linker

C.3. Understanding the Linker
	Appendix C. Development Tools

[ fromfile: linker.xml id: linker ]

Figure C.1. The Linker's inputs and outputs

Figure C.1 shows how the linker accepts binary files, which were generated by the compiler, and creates executable binaries as its output. The linker executable, on *nix machines, is called ld. It is run by g++ after all source files have been compiled successfully.

All these steps are performed when you run make, which prints out every command before it executes. By reading the output of make, you can see what arguments are passed to the compiler and linker. If an error occurs, it immediately follows the command-line that produced the error. Example C.4 shows the command-line options passed to g++, and attempts to show how g++ runs the linker, known as ld, and also passes some arguments to it.

Example C.4. linker-invocation.txt

    g++ -Wl,-rpath,/usr/local/qt-x11-free-3.2.3/lib            
        -o hw7                                                
        .obj/address.o .obj/ca_address.o .obj/constraintgroup.o
        .obj/customer.o .obj/dataobject.o .obj/dataobjectfactory.o
        .obj/hw07-demo.o .obj/us_address.o .obj/moc_address.o 
        .obj/moc_ca_address.o .obj/moc_customer.o .obj/moc_dataobject.o 
        .obj/moc_us_address.o  
        -L/usr/local/qt-x11-free-3.2.3/lib  -L/usr/X11R6/lib 
        -L/usr/local/utils/lib                                
        -lutils -lqt -lXext -lX11 -lm

	Tells g++ to run the linker, and pass these options to ld.
	Specify the output to be called hw7.
	Link these object files into the executable.
	Add another location for the linker to search for libraries.
	Link this app with five more libraries: qt utils, ext, X11, and m.

Linking entails the following:

For each library name passed with the -l switch, find the corresponding library file, searching the library path and all -L switched arguments (which were generated by qmake from the LIB qmake variable).
- For static libraries, it contains the binary code to be linked into the executable.
- For dynamic libraries, it is a catalog listing (often in readable ascii format) that describes where the actual shared objects are for each label definition. The linker checks to make sure the shared object is where it should be, and reports an error if not.
For each function call that is called from any place in the code we are linking, find the object where that code is located and do a simple, fast check to determine that there is, indeed, a completely defined function with the proper name/signature at that location. Report an error if it can't be found or isn't the correct type/name/size.
For each reference to a variable name, find the object-address where that variable is located and do a simple, fast check to make sure the address is a valid one for an object of that type.

This is the general idea. The linker resolves references to names by finding their real addresses in files and checking the addresses to see if they're valid for the type id. It's like a directory lookup service for C++ compilers.


C.2. The Preprocessor: For `#including` Files		C.3.1. Common Linker Error Messages