Improper handling of install name for shared library on OS X

[elfprince13]

I am working on a project that has hiredis as a submodule in our git repo. Since we want to keep the build process contained in a single (user-owned) directory tree, we make install with the make INSTALL="cp -R" PREFIX=$(pwd) install. I then find the following incorrect behavior when I run otool.

[thomas@Mithlond] hiredis $ otool -D lib/libhiredis.dylib
lib/libhiredis.dylib:
libhiredis.0.13.dylib

Note that since the install name is incorrectly set, linking against this copy of the library, even by absolute path, will produce a binary that can't find libhiredis.dylib without manually altering LD_LIBRARY_PATH.

[badboy]

I do not have access to a OSX macOS machine, so I need more information:
What does the output of otool mean?
What is wrong about it?
What is the expected output?

[elfprince13]

There's a good explanation here, but the short version is that dynamic libraries on OS X can "remember" where they're supposed to be located in the file system, and linking against them also records that location into the new executable/dependent library. This isn't important when the install directory is somewhere that the program loader searches by default, but super important when installing to a non-standard location (e.g. anywhere you can write to without sudo).

I suspect it should be sufficient to patch this line in the Makefile:
DYLIB_MAKE_CMD=$(CC) -shared -Wl,-install_name,$(DYLIB_MINOR_NAME) -o $(DYLIBNAME) $(LDFLAGS)
To:
DYLIB_MAKE_CMD=$(CC) -shared -Wl,-install_name,$(INSTALL_LIBRARY_PATH)/$(DYLIB_MINOR_NAME) -o $(DYLIBNAME) $(LDFLAGS)
But I'm not sure.

[xor-gate]

You could also use some tools to fixup the "remember" to relative paths based on @executable_path.
Nice tool: https://github.com/auriamg/macdylibbundler

[ryandesign]

You can't use $(INSTALL_LIBRARY_PATH) in the install_name because $(INSTALL_LIBRARY_PATH) includes $(DESTDIR). You have to use $(PREFIX)/$(LIBRARY_PATH) instead. Either way, it doesn't work right if the user has set LIBRARY_PATH in a way that the compiler understands, because the Makefile misuses LIBRARY_PATH; see #382.

[michael-grunder]

I'll get the Makefile updated this evening so we don't use GCC environment variables.