Deploying App that use dylibs on Mac OS X

dylibs can save you space, but only if you already have the library
installed. When shippings apps to Mac users, this can be a problem -
having to do anything other than drag an icon to your disk (or
decompress a .app.tgz) cuts into user appreciation. One way around
this is to include everything a user needs into the applicaiton
bundle. For frameworks this is cake: XCode provides a "copy
frameworks" build phase, and any frameworks that you add to this will
be copied into the bundle before they're linked (if not, make sure the
phase happens before the library link phase).

But I wouldn't be writing this post if that were the end of it.
dylibs are dynamic libraries, like DLL's on Windows, .so's on unix,
and the binary part of a Framework. dylibs contain references to
their locaiton on disk, which is a problem if you plan on moving them
to package them in your app's bundle. Mac OS X includes two utilities
that will help you fix this: otool, and install_name_tool. XCode's
"run script" build phase provides a convenient place to patch the
dylibs after you've copied them. Here's a short script that I use to
fix the paths of libgauche for my application:

#!/bin/bash
EXECFILE=${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
LIBPATH=${BUILT_PRODUCTS_DIR}/${SHARED_SUPPORT_FOLDER_PATH}
NEWLIBPATH="@executable_path/../SharedSupport"

# space separated list of libraries
TARGETS="libgauche.dylib"
for TARGET in ${TARGETS} ; do
LIBFILE=${LIBPATH}/${TARGET}
TARGETID=`otool -DX ${LIBPATH}/$TARGET`
NEWTARGETID=${NEWLIBPATH}/${TARGET}
install_name_tool -id ${NEWTARGETID} ${LIBFILE}
install_name_tool -change ${TARGETID} ${NEWTARGETID} ${EXECFILE}
done