site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thank you for your thoughts on this problem. On 11 Nov 2006, at 12:56, Jonas Maebe wrote: On 11 Nov 2006, at 13:44, Alan Fry wrote: man install_name_tool Hope this is of interest, Alan Fry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... The result of this is the binaries in '/usr/local/netpbm/bin' look for the 'dylib' at the top level instead of '/usr/local/netpbm'. On Mac OS X, a library's location isn't stored in the binary (so no -rpath), but in the library itself. And although this has been discussed at large in the past, I still don't understand the use of that (I do understand the use of not storing the library's location in the binary, but I do not understand why it is useful to limit a library to working only when it's installed in a particular location). It seems the binaries do contain the path to the shared libraries, so there is no searching to be done, hence there is no 'rpath' to define a runtime search path. Instead the linker option '-install-name' is invoked which puts the runtime path to the library into the executables that use it. The problem with 'netpmb' was partly a 'typo' in a 'make' variable which had the effect of the variable returning 'null' so that the executables then looked for the 'dylib' in the root directory. This has been corrected and all works fine now. The 'install_name_tool' incidentally failed because the executables in question were the wrong type, so it did not seem to be possible to modify the binaries after building the whole package. This email sent to site_archiver@lists.apple.com