I spent a little time trying to figure relative linking out with [Home]brew as apposed to linking a hardcoded '/use/local/...'. I have not spent much time at this yet, but when building libraries with Xcode for including in my OS X App bundle's '@executable_path' is used instead of a full hard system path. You can get info about your compiled libraries and dependencies with 'otool -L':
$ otool -L libboost_filesystem-mt.dylib libboost_filesystem-mt.dylib:
@executable_path/../Frameworks/libboost_filesystem-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
@executable_path/../Frameworks/libboost_system-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
You can change your dylib's dependency path's with 'install_name_tool'. Given a binary 'MyBinary':
$ otool -L MyBinary MyBinary:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/usr/local/lib/myLib.dylib (compatibility version 1.0.0, current version 1.0.0)
$ install_name_tool -change /usr/local/lib/myLib.dylib @executable_path/../Frameworks/myLib.dylib MyBinary
Whenever we recompile however we'll need to re-run install_name_tool. It turns out the root issue is how myLib.dylib was built... To fix this update the Makefile that generated myLib.dylib, and change it, adding the -install_name flag to the libtool line which might then look something like this:
libtool -dynamic -flat_namespace -install_name @executable_path/../Frameworks/myLib.dylib \ -lSystem -compatibility_version 1.0 -current_version 1.0.0 \ -o myLib.dylib -undefined suppress $(OBJS)
I'm still interested in a fairly generic way to shoehorn this into common configure scripts, but I haven't looked into it much at this point; it's just on my to-do list. I don't have an easily available comprehensive list of all the options I used, but these might assist others a bit:
CFLAGS="-arch x86_64 -arch i386" [-arch ppc] <- If you are building for PPC (or even can)
LDFLAGS="-arch x86_64 -arch i386" [-arch ppc]
building for backwards compatibility to an older SDK:
CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch x86_64 -arch i386"
You may need to add this flag to configure (when building fat binaries):
./configure --disable-dependency-tracking
You can also use the 'file' command or 'lipo -info' to check if 'fat' or 'slim' and or what architectures it's build for:
$ file libboost_filesystem-mt.dylib libboost_filesystem-mt.dylib: Mach-O universal binary with 2 architectures
libboost_filesystem-mt.dylib (for architecture x86_64): Mach-O 64-bit executable x86_64
libboost_filesystem-mt.dylib (for architecture i386): Mach-O executable i386
[ update 2011.04.11 @ 19:15 PT ]
Some more related info I found... "@rpath" may be better than "@executable_path"
Some more related info I found... "@rpath" may be better than "@executable_path"
http://www.dribin.org/dave/blog/archives/2009/11/15/rpath/
