title: What is the deal with undefined symbols in a shared library or dylib?
body: <p>I have a Makefile for linux that I am porting over to Darwin.  The makefile takes a bunch of .o files and links them together into a .so shared object.  Okay, so I figured (am I wrong about this?) that the best analog for this in Darwin is the dylib.  So I changed the -shared flag to -dynamiclib.</p>
  
  <p>Now the code that I am linking together into the dylib depends on lots of external libraries.  When I try to build the dylib, I get errors saying there are undefined references.  But the Linux Makefile does not specify any of the -lwhatever or -L/path/whatever options in the build step that creates the .so file.  Hm?  Is this because when you create an ELF .so file, by default it leaves external references unresolved, and then when the shared library is loaded, it <em>recursively</em> loads shared libraries which are depended on by the shared library you are loading?  Wouldn't it be the case that if the shared library depends on a .a or .o file, you would HAVE to statically link them into the shared library, otherwise you could not link at runtime?  How can you get away with having undefined references in a library that is loaded at runtime, unless the references are also to dynamically loadable libraries?</p>
  
  <p>Anyway so if I specify</p>
  
  <pre><code>-undefined suppress -flat_namespace
  </code></pre>
  
  <p>it doesn't require me to add those -l and -L options when creating the shared library.  But I still don't understand how this can work ultimately.</p>