gcc ld_library_path - I don't understand -Wl,-rpath -Wl,
how to (5)
-Wl,xxx option for gcc passes a comma-separated list of tokens as a space-separated list of arguments to the linker. So
eventually becomes a linker call
ld aaa bbb ccc
In your case, you want to say "
ld -rpath .", so you pass this to gcc as
-Wl,-rpath,. Alternatively, you can specify repeat instances of
gcc -Wl,aaa -Wl,bbb -Wl,ccc
Note that there is no comma between
aaa and the second
Or, in your case,
For convenience I added the relevant manpages below.
My (mis)understanding first: If I need to separate options with
,, that means that the second
-Wl is not another option because it comes before
, which means it is an argument to the
I don't understand how
-rpath can have a
What would make sense in my mind would be this:
This should invoke -rpath linker option with the current directory argument.
Pass option as an option to the linker. If option contains commas, it is split into multiple options at the commas. You can use this syntax to pass an argument to the option. For example,
-Map output.mapto the linker. When using the GNU linker, you can also get the same effect with `-Wl,-Map=output.map'.
Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link;
You could also write
To get rid of that pesky space. It's arguably more readable than adding extra commas (it's exactly what gets passed to ld).
One other thing. You may need to specify the -L option as well - eg
-Wl,-rpath,/path/to/foo -L/path/to/foo -lbaz
or you may end up with an error like
ld: cannot find -lbaz
The man page makes it pretty clear. If you want to pass two arguments (
.) to the linker you can write
-Wl,-rpath . you suggested do NOT make sense to my mind. How is gcc supposed to know that your second argument (
.) is supposed to be passed to the linker instead of being interpreted normally? The only way it would be able to know that is if it had insider knowledge of all possible linker arguments so it knew that
-rpath required an argument after it.
Found by experimentation, and inspecting the command lines generated by Xcode for a reference rpath demo project by Dave Driblin:
otool -L shows you the install name of the linked libraries. To get
@rpath to work, you need to change the install name of the library:
$ gcc -dynamiclib blah.o -install_name @rpath/t/libblah.dylib -o libblah.dylib $ mkdir t ; mv libblah.dylib t/ $ gcc main.c -lblah -L`pwd`/t -Xlinker -rpath -Xlinker `pwd`