Can someone please give me a basic rundown of how the compiling and linking stages work. Take for example the basic begining code snippet.

#include <stdio.h>
void main()
{
printf("Hello World");
}

Ok, the # causes the preprocessor program to run. But what exactly does the preprocessor do??? The include tells the compiler to "include" stdio.h in the the program. Does this mean that the code in stdio.h will be added to my source file or does it just provide a reference to the stdio.h file so it can find the instructions for how to handle printf()???? After compilation and i have the .obj the linker adds code modules from the program libraries. Are the program Libraries header files??? I am just trying to get a more thorough understaning of how the how compiling/linking process works??

Does the compiling stage just take the .c/.cpp file and turn everything in the file into machine code and the linking process is what combines the .obj file with the .h file??


Any help is greatly appreciated,
Thanks

#include <stdio.h>

This first line of the program is a preprocessing directive, #include. This causes the preprocessor—the first tool to examine source code when it is compiled—to substitute for that line the entire text of the file or other entity to which it refers. In this case, the header file stdio.h—which contains the definitions of standard input and output functions—will replace that line. The angle brackets surrounding stdio.h indicate that the file can be found within one of the locations given to the preprocessor through the search path for header files.

Linker:

A linker takes the object code generated by the compiler / assembler, and links it against the C library (and / or libgcc.a or whatever link library you provide). This can be done in two ways: static, and dynamic.
Static Linking

When linking statically, the linker is invoked during the build process, just after the compiler / assembler run. It takes the object code, checks it for unresolved references, and checks if it can resolve these references from the available libraries. It then adds the binary code from these libraries to the executable; after this process, the executable is complete, i.e. when running it does not require anything but the kernel to be present.

On the downside, the executable can become quite large, and code from the libraries is duplicated over and over, both on disk and in memory.
Dynamic Linking

When linking dynamically, the linker is invoked during the loading of an executable. The unresolved references in the object code are resolved against the libraries currently present in the system. This makes the on-disk executable much smaller, and allows for in-memory space-saving strategies such as shared libraries (see below).

On the downside, the executable becomes dependent on the presence of the libraries it references; if a system does not have those libraries, the executable cannot run.
Shared Libraries

A popular strategy is to share dynamically linked libraries across multiple executables. This means that, instead of attaching the binary of the library to the executable image, the references in the executable are tweaked, so that all executables refer to the same in-memory representation of the required library.

This requires some trickery. For one, the library must either not have any state (static or global data) at all, or it must provide a seperate state for each executable. This gets even trickier with multithreaded systems, where one executable might have more than one simultaneous control flow.

Second, in a virtual memory environment, it is usually impossible to provide a library to all executables in the system at the same virtual memory address. To access library code at an arbitrary virtual address requires the library code to be position independent (which can be achieved e.g. by setting the -PIC command line option for the GCC compiler). This requires support of the feature by the binary format (relocation tables), and can result in slightly less efficient code on some architectures.

Regards,
Paramesh.

"Don't walk behind me; I may not lead.
 Don't walk in front of me; I may not follow.
 Just walk beside me and be my friend."

One last question. In beginning C ivor referes to program libraries as code modules that are not part of C but provide operations like finding the square root. By program libraries is he refering to Header files and what does he mean by not being part of the C language?

thanks

Libraries are user created codes that do not ship with the C compiler or are not part of the C language. Because it is user defined.

Program libraries also include header files.

and Welcome to the GID forums. :)

Regards,
Paramesh.

"Don't walk behind me; I may not lead.
 Don't walk in front of me; I may not follow.
 Just walk beside me and be my friend."

so basically program libraries are just code modules that are created by individuals to use in the programs. Then during the linking process theses libraries are combined with the .obj code to provide the proper definitions of the functions.

Am i understanding this correctly?

thanks

There are two types.
One is the standard C libraries and the other one is created by individuals(you will learn about that soon).

:)
Regards,
Paramesh.

"Don't walk behind me; I may not lead.
 Don't walk in front of me; I may not follow.
 Just walk beside me and be my friend."

one thing i am still a little unsure about. In the beginning C book he says that the Compiler is instructed to "include" in our program the file stdio.h

Since you said "the preprocessor—the first tool to examine source code when it is compiled—to substitute for that line the entire text of the file or other entity to which it refers."

So when he says the compiler is instructed to "include" does he just mean that the compiler will convert the code that the preproccesor adds into machine code along with the rest of the file??

Also if the preproccessor is adding the header file to the source file then what files does the linker link when it creates the exe file since the header file is already included

I think yes.
I am not sure about the answer. Try posting this in the Forums.

Regards,
Paramesh.

"Don't walk behind me; I may not lead.
 Don't walk in front of me; I may not follow.
 Just walk beside me and be my friend."

the preprocessor, as far as "#include" 's go, is a substitution tool. It does paste the code from the included file into the file it is being included in, as stated in a previous post. When you compile code, unless otherwise specified, a obj file is created (for me .obj files are created). The linker then links these .obj files; so that one .obj file may reference code in the other compiled .obj files, in this situation.