Related, but do not answer the question:
On OSX, I have a dynamic library provided by a packager manager, installed in a non standard directory, which install_name is just the filename. For example:
$ ROOT=$PWD
$ mkdir $ROOT/foo
$ cd $ROOT/foo
$ echo 'int foo(int a, int b){return a+b;}' > foo.c
$ clang foo.c -dynamiclib -install_name libfoo.dylib -o libfoo.dylib
I don't want to change (absolute path, @RPATH, ...) the install_name of
libfoo.dylib using install_name_tool -id
.
Now I link a program with the library, for example:
$ mkdir $ROOT/bar
$ cd $ROOT/bar
$ echo 'int foo(int,int); int main(){return foo(2,4);}' > main.c
$ clang main.c -L../foo -lfoo
The program can't run:
$ ./a.out
dyld: Library not loaded: libfoo.dylib
Referenced from: $ROOT/bar/./a.out
Reason: image not found
Trace/BPT trap: 5
because:
$ otool -L ./a.out
./a.out:
libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
I can change the path of the dependant library:
$ install_name_tool -change libfoo.dylib ../foo/libfoo.dylib a.out
so:
$ otool -L ./a.out
./a.out:
../foo/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
and the program can execute:
$ ./a.out
$ echo $?
6
Is there a clang option I can add to the command:
$ clang main.c -L../foo -lfoo
to avoid having to run:
$ install_name_tool -change libfoo.dylib ../foo/libfoo.dylib a.out
Note: I don't want to modify DYLD_LIBRARY_PATH
or such other environment variable.
?
I've been hitting my head against this for some time and think I have finally figured out how to do this without using
install_name_tool
, at least for Mac OS 10.9 and later (as far as I've tested).While you may have already figured this out, I'm posting it here in case anyone else needs it.
Basically you have two options:
install_name
in terms of@executable_path
@rpath
, which you then set when you compile the executable:The end result will be the same in both cases:
The second one is probably preferable, since then you can compile the library once, and have any executable that uses it define where it will load it from using its own
rpath
.Please check here for detailed explanations of
@executable_path
,@rpath
and@load_path
(which I did not use here).