On Dec 14, 2007 1:30 AM, Christian Maeder
Ian Lynagh wrote:
Incidentally, I suspect the otool output actually means it depends on /some/ libgmp.3.dylib, and it is using one that it found in /opt/local/lib/libgmp.3.dylib, but I could be wrong.
The full path /opt/local/lib/libgmp.3.dylib is (somehow) stored in the binary, but libgmp.3.dylib will be found in any other path, too. Possibly the DYLD_LIBRARY_PATH has to be set for uncommon paths.
Today I did some digging around the source of dyld (the dynamic loader) to understand its behavior when loading frameworks, and ended up learning about how it loads ordinary libraries as well. In particular, if otool -L lists a dependency on /opt/local/lib/libgmp.3.dylib, then the loader will look for all of the following: - [[dir]]/opt/local/lib/libgmp.3.dylib where [[dir]] is any entry from the colon-separated variable $DYLD_ROOT_PATH - /opt/local/lib/libgmp.3.dylib - [[dir]]/libgmp.3.dylib, where [[dir]] is any entry from the following colon-separated variables: - LD_LIBRARY_PATH - DYLD_LIBRARY_PATH - DYLD_FALLBACK_LIBRARY_PATH If DYLD_FALLBACK_LIBRARY_PATH is not set in the environment, it defaults to: "$HOME/lib:/usr/local/lib:/usr/lib" The rest of the variables listed above default to empty. So in conclusion, there should be no harm with linking OS X binaries against absolute paths like /opt/local. In fact, it might be preferable, since it lets us support both users of MacPorts and users who have GMP stored in a standard location. (Of course, this doesn't address the question of whether dynamically linking against GMP is good to begin with.) Best, -Judah