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


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:

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:

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


reply via email to

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