title: Linking against shared objects at compile time
body: <p>In Windows, many .dlls come with a static .lib counterpart.  My understanding is that the .lib counterpart basically contains LoadProcAddress calls so that the programmer doesn't have to do it him/herself.  Essentially, a time saver.  When I switched to Linux, I was assuming the situation was the same, replacing .dll with .so and .lib with .a, but I have come to a situation that is showing me this is wrong and I can't figure out what is going on:</p>
  
  <p>I am using a library that comes as a .a/.so pair.  I was linking against the .a, but when I executed ldd on the binary that was produced, it contained no reference to the corresponding .so file.  So then, I tried linking against the .so file and to my surprise, this worked.  In addition, the .so file showed up when I executed ldd against the resulting binary.  </p>
  
  <p>So, I am really confused as to what is going on.  In Windows, I would never think to link against a .dll file.  Also, in Windows, if a .dll file was accompanied with a .lib and I linked against the .lib at compile-time, then I would expect to have a dependency on the corresponding .dll at runtime.  Both these things are not true in this case.</p>
  
  <p>Yes, I have read the basic tutorials about shared objects in Linux, but everything I read seems to indicate that my initial assumption was correct.  By the way, I should mention that I am using Code::Blocks as an IDE, which I know complicates things, but I am 99% sure that when I tell it to link against the .so file, it is not simply swapping out the .a file because the resulting binary is smaller.  (Plus the whole business about ldd...)</p>
  
  <p>Anyway, thanks in advance.  </p>