What is the deal with undefined symbols in a shared library or dylib?

Question

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.

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 recursively 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?

Anyway so if I specify

-undefined suppress -flat_namespace

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.

Answer 1

This thread also discusses this issue. I think the key point is that in order to get the Linux-like linking behavior, you need to specify the "-undefined dynamic_lookup" flag. By default, the Darwin linker throws an error if there are any undefined references in a dynamic library. You can also use -U to set this behavior on a per-symbol basis. See 'man ld' for reference.