Re: -rpath unrecognised by linker
Re: -rpath unrecognised by linker
- Subject: Re: -rpath unrecognised by linker
- From: Alan Fry <email@hidden>
- Date: Thu, 16 Nov 2006 10:51:17 +0000
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:
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'.
man install_name_tool
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.
Hope this is of interest,
Alan Fry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden