views:

42

answers:

1

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.

A: 

Use libtool.

libtool -dynamic -multiply_defined suppress -install_name `basename ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib` -o ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib   ../../../../rlp/lib/universal-darwin9-gcc40/libbtd.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttrie.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtkey.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtunit.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtutilities.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtopts.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxcode.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtprops.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxml.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake3.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake5.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtac.a  -lstdc++.6 -lgcc_s.10.4 ../../../../build_system/lib/universal-darwin9-gcc40/libgcc.a -lSystem -lSystemStubs`
bmargulies
Thanks, I think that will work, but I am also interested in the background behind what is happening.
eeeeaaii
MacOS isn't quite linux. It's originally NextOS, after all. The linker is a bit eccentric. Add -v to the libtool and it will tell you what it is doing.
bmargulies