Conflict between dynamic linking priority in OSX?

Question

There is a dynamic-linking-conflict between different libjpeg dynamic libraries on OSX. First there is a standard native libJPEG.dylib (in /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/). But if you are using MacPorts, you can also have a port-related libjpeg.dylib in (in /opt/local/lib). The latter may for example have been installed as a dependency for some other port.

This creates a problem when you link against your system libJPEG (which is preferred). Then if /opt/local/lib is in DYLD_LIBRARY_PATH, that path will be prioritised when searching for a dynamic lib, resulting in a runtime error when loading symbols:

dyld: Symbol not found: __cg_jpeg_resync_to_restart
 Referenced from:
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
 Expected in: /opt/local/lib/libJPEG.dylib
in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
Trace/BPT trap: 5

So I have two questions (likely related):

1. What is a good way of solving the actual problem (removing /opt/local/lib from DYLD_LIBRARY_PATH obviously solves it but creates problems for other dependencies)?

2. What other paths are searched for dynamic libs (I.e. Where is the "/System/Library" path specified) and why does DYLD_LIBRARY_PATH rank higher priority-wise?

Answer 1

I experienced similar problem while using OpenCV in MacOS El Capitan. Solved the problem using the solution in the link

Solution is to delete some dlylibs in the /usr/local/lib directory and create symbolic links to related files /System/Library/Frameworks/ImageIO.framework/Resources/

cd /usr/local/lib
rm libgif.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libGIF.dylib libGIF.dylib
rm libjpeg.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libJPEG.dylib libJPEG.dylib
rm libtiff.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libTIFF.dylib libTIFF.dylib
rm libpng.dylib
ln -s /System/Library/Frameworks/ImageIO.framework/Resources/libPng.dylib libPng.dylib

Answer 2

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.

Answer 3

If using Qt Creator, you have to uncheck the Add build library search path to DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH option from the Run section in the Projects tab: