[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Libtool fails to build working binary when -no-install is used
From: |
Simon Josefsson |
Subject: |
Re: Libtool fails to build working binary when -no-install is used |
Date: |
Wed, 4 Apr 2007 00:51:54 +0200 |
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:
-headerpad_max_install_names (32-bit only)
Add to the header padding enough space to allow
changing all
dynamic shared library paths recorded in the output
file to be
changed to MAXPATHLEN in length.
/Simon