changing the path of a dylib using install_name_tool

Question

install_name_tool -change /usr/local/lib/testlib.dylib  "$TARGET_BUILD_DIR"/../../testlib.dylib "$PRODUCT_NAME"

I was told the above when put into a run script in xcode would change the lookup path of a dynamic library. this can then be verified by entering the following into a terminal window

otool -L /drag/the/executable/here/and/its/filepath/will/show/up/testlib

the output will be something like the following

/previous/filepath:
/usr/local/lib/testlib.dylib (compatibility version 1.0.0, current version 1.0.0)
./anothertestlib.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

My question is why wouldn't the install_name_tool command work? It isn't right now but it did when testlib project was was a target dependancy of a client project. Now I have just dragged the .dylib in to the client project. the lookup path stays in usr/local/lib.

And also, what is usr/local/lib, why does the system think my dylib is in there, and how did it get in there?

Answer 1

install_name_tool works by overwriting the path strings, so any new one has to be the same length or shorter than the original one.

Because "/usr/local/lib/testlib.dylib" is 28 characters long and ""$TARGET_BUILD_DIR"/../../testlib.dylib" is at least 20 characters long, if the $TARGET_BUILD_DIR variable expands to a string of 9 characters or more then the replacement will probably be too long to use.

I say probably because you can add the flag -headerpad_max_install_names to the linker so that it will add padding after each path so the space will exist to allow longer replacements (I believe up to 1,024 characters). Though as install_name_tool is failing then this was probably not used.

As for the /usr/local/lib path, technically /usr (/usr/bin, /usr/lib etc.) is used for software that applies to any machine and which can be mounted on a network, while the /usr/local root (/usr/local/bin, /usr/local/lib) is for anything specific to just the local machine. In practice it is more the case that packages supplied via an OS distribution users /usr and custom installs use /use/local. For the most part it does not matter. On the Mac specifically the Homebrew package manager uses the /usr/local root (while MacPorts uses /opt and Fink /sw).

It just happens that whatever you did to originally install it used that location over any of the other options. But so long as whatever requires it knows where to look, it is no more or less a valid location.