On 4 apr 2007, at 00.21, Peter O'Gorman wrote:
On Apr 3, 2007, at 5:16 PM, Simon Josefsson wrote:
On 3 apr 2007, at 23.44, Ralf Wildenhues wrote:
Do I understand correctly that Darwin has no way to hardcode
library
paths (other than the ones given by -install-name)? OK to apply
and
backport? It fixes the stresstest failure exposed by my last
patch.
After some experiments and a lot of man page reading on my
powerbook, I believe this is correct. I was rather surprised to
not find anything like -R or -Wl,-rpath on Mac OS X, so it may be
that I missed something. Still, this patch is the best we can do
without more information from Mac OS X experts.
There is no -rpath on Mac OS X 10.4 and earlier, it is, or at
least was, I believe, a planned feature for 10.5, but plans and
reality don't always intersect...
Right.
FWIW, I did find -dylib_file which seems relevant:
-dylib_file install_name:file_name(32-bitonly)
Specifies that a dynamic shared library is in a
different loca-
tion than its standard location. Use this option
when you link
with a library that is dependent on a dynamic
library, and the
dynamic library is in a location other than its
default loca-
tion. install_name specifies the path where the
library nor-
mally resides. file_name specifies the path of the
library you
want to use instead. For example, if you link to a
library that
depends upon the dynamic library libsys and you
have libsys
installed in a nondefault location, you would use
this option:
-dylib_file /lib/libsys_s.A.dylib:/me/lib/
libsys_s.A.dylib.
However, I cannot get it to do anything at all on my machine. The
hard coded path to the library seems to be the one stored inside
the library, no matter what I supply as -dylib_file parameter when
linking the binary.
However, after seeing this thread:
http://www.cocoabuilder.com/archive/message/cocoa/2003/12/3/868
I discovered the install_name_tool command, and it do seem to solve
the problem:
espresso:~ jas$ cd p
espresso:~/p jas$ cat foo.c
void test (void) { puts("test"); }
espresso:~/p jas$ gcc -dynamiclib -o libfoo.dylib -install_name /
Users/jas/libfoo.dylib foo.c
espresso:~/p jas$ cd ..
espresso:~ jas$ ls *foo*
ls: *foo*: No such file or directory
espresso:~ jas$ cd t
espresso:~/t jas$ cat main.c
int main() { test(); }
espresso:~/t jas$ gcc -o main main.c -L/Users/jas/p -lfoo -
headerpad_max_install_name
sespresso:~/t jas$ otool -L main
main:
/Users/jas/libfoo.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.8)
espresso:~/t jas$ ./main
dyld: Library not loaded: /Users/jas/libfoo.dylib
Referenced from: /Users/jas/t/./main
Reason: image not found
Trace/BPT trap
espresso:~/t jas$ install_name_tool -change /Users/jas/
libfoo.dylib /Users/jas/p/libfoo.dylib main
espresso:~/t jas$ otool -L mainmain:
/Users/jas/p/libfoo.dylib (compatibility version 0.0.0,
current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.8)
espresso:~/t jas$ ./main test
espresso:~/t jas$
So if you want to solve this without a wrapper, you should link the
-no-install programs with -headerpad_max_install_name and run
install_name_tool translating the installed name of libraries into
whatever is the non-installed name for each shared library.
Presumably, that has to be done recursively for all shared library
(in case there are multiple non-installed shared libraries that
depend on each other). And it only works for 32-bit hosts: