title: How exactly does linking work?
body: <p>The way I understand the compilation process:</p>
  
  <p>1) Preprocessing:  All of your macros are replaced with their actual values, all comments are removed, etc. Replaces your #include statements with the literal text of the files you've included.</p>
  
  <p>2) Compilation:  Won't drill down too deep here, but the result is an assembly file for whatever architecture you are on.</p>
  
  <p>3) Assembly: Takes the assembly file and converts it into binary instructions, i.e., machine code.</p>
  
  <p>4) Linking: This is where I'm confused.  At this point you have an executable.  But if you actually run that executable what happens?  Is the problem that you may have included *.h files, and those only contain function prototypes?  So if you actually call one of the functions from those files, it won't have a definition and your program will crash?</p>
  
  <p>If that's the case, what exactly does linking <em>do</em>, under the hood? How does it find the .c file associated with the .h that you included, and how does it inject that into your machine code?  Doesn't it have to go through the whole compilation process again for that file?</p>
  
  <p>Now, I've come to understand that there are two types of linking, dynamic and static.  Is static when you actually recompile the source of the library for every executable you create?  I don't quite understand how dynamic linking would work.  So you compile one executable library that is shared by all of your processes that use it?  How is that possible, exactly?  Wouldn't it be outside of the address space of the processes trying to access it?  Also, for dynamic linking, don't you still need to compile the library at some juncture in time?  Is it just sitting there constantly in memory waiting to be used?  When is it compiled?  </p>
  
  <p>Can you go through the above and clear up all of the misunderstandings, wrong assumptions there and substitute your correct explanation?</p>