Why is install_name_tool and otool necessary for Mach-O libraries in Mac Os X?

Question

I am developing a Cocoa Application using the latest version of Xcode 4, I want to link dynamic libraries to my project (dylibs).

I read somewhere that adding the libraries in my project was not enough as I have to run install_name_tool and otool to make my project use the libraries that were bundled in my project.

I have read the manual pages for install_name_tool, but I do not understand WHY I have to do this.

How do libraries work? Especially interested in the part where the application and the libraries have paths that point to specific places in my machine, like /usr/local/lib/mylibrary.dylib when running otool -L

Solution 1

Apple has several ways of locating shared libraries:

1. @executable_path : relative to the main executable
2. @loader_path : relative to the referring binary
3. @rpath : relative to any of a list of paths.

@rpath is the most recent addition, introduced in OS X 10.5.

If for instance you want to have your executable in Contents/MacOS and libraries in Contents/Libraries you could do the following:

install_name_tool -id @rpath/Libraries/lib_this.dylib   builddir/lib_this.dylib

and in the top-level executable set rpath with:

install_name_tool -add_rpath @loader_path/..  myexecutable

and:

install_name_tool -change builddir/lib_this.dylib @rpath/Libraries/lib_this.dylib myexecutable

Note: that the first path after -change must match exactly what is currently in the binary.

If you get lost otool -l -v myexecutable will tell you what load commands exactly are currently in the executable.

See man dyld and man install_name_tool for more information.

Solution 2

There is also a GUI tool named MacDependency which will expose all dependent libraries (https://github.com/kwin/macdependency/).

Comments

[par]

otool -L is also helpful to display the names and shared libraries (that you might want to change with install_name_tool.

[geowar]

Note: install_name_tool fails silently; always double check that it actually did what you told it to do (using 'otool -L <path_to_dylib>'.

[v.shashenko]

It seems that the attributes in a dylib don't really matter. They are used only when linking an executable to the dylib to copy the attributes from the dylib to the executable. For the case when you already have an executable linked to a dylib but you need to change the paths, then it's enough to edit only the executable to set LC_LOAD_DYLIB and, optionally, LC_RPATH. The second is needed only if the first one has @rpath in it.

[M Katz]

The part that saved me was: "Note: that the first path after -change must match exactly what is currently in the binary." I hadn't realized that it was necessary to include the full path as it appears in the otool -L dump. in my case that path was /usr/local/lib/libcrypto.1.1.dylib and it wasn't working if I just used libcrypto.1.1.dylib for that parameter.