Using an external .dyld with incorrect install_name

[ndevenish (Nicholas Devenish)]

I’m linking to an external library /abs/path/lib/libexternal.dylib. The dylib has it’s -install_name/Library ID set to the relative path "lib/libexternal.dylib".

When I link to this from my downstream application, it fails to load the library at run-time, unless I run from the cwd or /abs/path, because regardless of how I seem to give the dyld to the linker the “dependent library install name” is copied directly:

$ otool -L test.so
test.so:
	test.so (compatibility version 0.0.0, current version 0.0.0)
	lib/libexternal.dylib (compatibility version 0.0.0, current version 0.0.0)

Setting CMake _RPATH* flags was my first attempt at solving, but doesn’t touch the problem, because this relationship appears to be handled by the linker/loader directly.

Assuming that I cannot “fix” the upstream library on a short timescale (which gets around this by setting DYLD_LIBRARY_PATH in all of their scripts), how can I work around this problem in CMake?

Are my only options either fixing upstream, or adding a custom install_name_tool compilation step that corrects the search path of my module (to e.g. either absolute or @rpath/)?

[ben.boeckel (Ben Boeckel (Kitware))]

@ndevenish

Setting CMake _RPATH* flags was my first attempt at solving, but doesn’t touch the problem, because this relationship appears to be handled by the linker/loader directly.

Right. macOS only uses any RPATH setting for @rpath/ library IDs.

@ndevenish

I’m linking to an external library /abs/path/lib/libexternal.dylib. The dylib has it’s -install_name/Library ID set to the relative path "lib/libexternal.dylib".

This is just broken.

I recommend using install_name_tool to fix the external’s ID to at least use @rpath/ as a prefix. You can then provide an rpath setting to get it found in your project. Fixing upstream would be even better, but you can fix the ID locally at least in the meantime.