Which stage of building a fully executable program form C source code combine multiple files into an executable program?

Answer 1

It's actually 3 stages: preprocessing, compilation and linking.

Preprocessing deals with all the preprocessor directives (all lines beginning with #). So a line such as #include<stdio.h> will effectively copy/paste the contents of the stdio.h header in place of the directive. The header itself may also contain preprocessor directives and these must be processed prior to insertion. Macros are also processed at this stage and all comments are stripped out. The end result is a translation unit that contains pure C code with absolutely no macros, no directives and no comments whatsoever. The translation unit is usually stored in working memory, however your IDE may include a switch that allows you to examine the contents of the translation unit.

The compiler processes each translation unit in isolation. Since the compiler cannot see any other translation units, only names with internal linkage can be resolved at compile time. The compiler produces an object file from the translation unit. The object file contains machine code along with a table of any names that couldn't be resolved by the compiler (those with external linkage).

Once all translation units have been compiled, the linker can examine the object files and resolve the outstanding external linkage problems, essentially linking all the object files into a single executable.

Problems can occur at any stage. For instance, preprocessing could result in a macro expansion that generates code that cannot be compiled. The compiler cannot resolve these problems because the compiler never saw the macro, it only saw the code that was generated by the preprocessor. So although it can identify the problem in the translation unit, it cannot identify where that problem originated. This is why macros are so difficult to debug: the compiler cannot help you.

Aside from macro problems, the compiler can identify and help you resolve a wide range of problems in your code thus it pays to make use of it as much as possible. The compiler can also statically assert your assumptions, perform compile-time computations and optimise your code through inline expansion, thus ensuring your code is error free and operates at peak performance.

Link-time errors are more difficult to deal with, but usually mean you've violated the one-definition rule (ODR) in some way, either by providing two different definitions for the same name or by not providing any definition of a name.

Even if no errors occur and linking is successful, it does not mean your executable is error free. The computer will only do exactly what you've told it to do, but it cannot account for logic errors at runtime. Many of these can be caught at compile time by making prudent use of static assertions, however this isn't always possible so you should also provide "sanity" checks wherever necessary and include appropriate error handling wherever runtime logic cannot be guaranteed to hold.