title: Misunderstanding concerning g++, dynamic and static linking on linux vs windows
body: <p>I'm a little confused by what I've learned today. I hope somebody can help me out.</p>
  
  <p>I understand the concept of dynamic and static linking, but the problem is as follows. On windows, or at least the paradigm on windows, you can have a .lib (which is like .a) and .dll (which is like .so, except... different) and you must statically link in the .lib which contains code that calls functions from the dll at runtime. Is this correct? In other words, gcc or g++ must have .lib files available at compile/link time, and be able to find .dll files at runtime. Please correct any wrong assumptions here.</p>
  
  <p>However, I'm splitting a few of my source files in my small application away because I want to make them a library. When I run g++ on my object files, with the -shared option, this basically creates a shared library (.so)? This is where the confusion arises. The <em>same</em> so file is needed <em>both</em> at link time and runtime? I have trouble understanding how I need it in the -L/-l option at link time but it still needs the file at runtime. Is this actually the norm? Is a dll fundamentally different?</p>
  
  <p>Finally, a final question. Take a library like boost on Windows. I built boost according to the instructions. In the end, the stage/lib directory contains libraries in a repeating sequence of name.a, name.dll.a, name.dll. What is the purpose of this scheme? I know I need the dll files at runtime, but when I use the -L/-l option at link time, what files is it using THEN?</p>
  
  <p>Sorry if this is really scattered, but I hope someone can help clear this up. Thanks a lot!</p>