So I'm porting a game from Linux to OS X and having successfully compiled and linked it, I'm now running up against problems starting it – the dynamic linker can't find the libs.
Here's the otool -L output:
./foo:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
@rpath/SDL2.framework/Versions/A/SDL2 (compatibility version 1.0.0, current version 3.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
/usr/lib/libGLEW.1.10.0.dylib (compatibility version 1.10.0, current version 1.10.0)
/usr/lib/libtheoradec.1.dylib (compatibility version 3.0.0, current version 3.4.0)
/usr/lib/libtheora.0.dylib (compatibility version 4.0.0, current version 4.10.0)
/usr/local/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.7.0)
/usr/local/lib/libogg.0.dylib (compatibility version 9.0.0, current version 9.2.0)
@loader_path/libsteam_api.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/macosx/some/path/to/code/openal-soft-1.16.0/build/libopenal.1.dylib (compatibility version 1.0.0, current version 1.16.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
The thing is, some of those paths are plain wrong. For instance, neither GLEW nor Ogg/Vorbis/Theora exist in /usr/…, and for whatever reason the path to OpenAL Soft is burnt in as an absolute one to where it was built.
Still, by setting DYLD_LIBRARY_PATH correctly, I can get the game to start. However, for multiple reasons I'd prefer not to embed my system's absolute paths within the binary.
What's going on here? Is there a way to force relative paths (that's the @loader_path thing, I presume?) on libraries of my choice? Is there documentation on the matter available?
Just as @trojanfoe suggested – this works:
install_name_tool -change <from> <to> <executable>