Hi, ----- On 20 Feb, 2018, at 15:34, Joshua Kordani jkord...@lsa2.com wrote:
> Not the OP, but regarding DYLD_LIBRARY_PATH, I don't understand how to > make use of dylib's provided by macports in my own programs without > setting this flag. I've read in several places that, esp with macports, > this should not be necessary, but I don't know what the *right way* is. macOS is not Linux in this regard. macOS libraries are referenced from binaries using their absolute path. At a technical level, when you link a binary with, for example, -lcurl on the command line, the linker will locate libcurl.dylib in the search paths you've given on the command line (that should be -L/opt/local/lib for use with MacPorts). It will then read the library id from the file. For our example of MacPorts' libcurl, this is: $> otool -D /opt/local/lib/libcurl.dylib /opt/local/lib/libcurl.4.dylib This path will then be copied into the linked binary. You can verify this with the MacPorts curl binary: $> otool -L /opt/local/bin/curl | grep libcurl /opt/local/lib/libcurl.4.dylib (compatibility version 10.0.0, current version 10.0.0) When you run /opt/local/bin/curl, the loader reads this table and locates this file using its absolute path. Setting DYLD_LIBRARY_PATH overrides this and attempts to locate a file with the given basename in the directories given in DYLD_LIBRARY_PATH, but if the library and the binary have been built correctly (and not moved) you should never have to set it. Of course this makes your binaries non-relocatable. If you want to relocate binaries, you can use relative paths using the special variables @loader_path, @executable_path and @rpath. See the dylibbundler port, which largely automates this if you built your binaries with the -headerpad_max_install_names linker flag (which MacPorts does by default). -- Clemens Lang
