[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: Peter O'Gorman
Subject: Re: Libtool fails to build working binary when -no-install is used
Date: Tue, 3 Apr 2007 17:56:19 -0500

On Apr 3, 2007, at 5:51 PM, Simon Josefsson wrote:

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...


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.

-dylib_file is only for the static linker to find dependent libraries, it does nothing for the dynamic linker.

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:

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
/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:

That would be overkill.

Peter O'Gorman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]