You should not set library paths using DYLD_LIBRARY_PATH
. As you've discovered, that tends to explode. Executables and libraries should have their library requirements built into them at link time. Use otool -L
to find out what the file is looking for:
$ otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO:
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
...
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
For an example of one of my homebrew-built programs:
$ otool -L /usr/local/bin/gifcolor
/usr/local/bin/gifcolor:
/usr/local/Cellar/giflib/4.1.6/lib/libgif.4.dylib (compatibility version 6.0.0, current version 6.6.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
Note that it references /usr/local
. If you've built it in such a way that it references the wrong library, I recommend rebuilding and pointing it to the correctly library.
If that's impossible, it is possible to edit what path is used using install_name_tool
, but there are cases where this doesn't work, such as if the new path is longer than the old path and you didn't link it with -header_pad_max_install_names
. Rebuilding with the correct path is preferred.
Note that there are a few "special" paths available that allow libraries to be found relative to their loader. See @executable_path/
and its kin in the dyld(1)
man page.