Rationale and intended use behind 'library-path', 'rpath', and 'rpath-link'
Asked Answered
C

0

7

I noticed many people, including me, do not accurately know the rationale and intended use behind the linker's search paths: 'library-path', 'rpath', and 'rpath-link'. Could someody explain this to us?

Context

After all my reading I am inclined to think 'library-path' and 'rpath' should be enough. The rationale and intended use of 'rpath-link' is a mystery to me. Let me explain why.
Setting the 'library-path' passes the specified paths to the linker to look for libraries at the specified paths at link(/build) time.
Setting the 'rpath' stores the specified paths in the built executable, the linker subsequently looks at the specified paths when the application is ran, i.e. at run time.
So, if your libraries reside at non-standard places, then you you need to specify 'library-path' to build your executable and 'rpath' to run it.
Now the GNU linker documentation says: "The difference between -rpath and -rpath-link is that directories specified by -rpath options are included in the executable and used at runtime, whereas the -rpath-link option is only effective at link time."
This raises two questions:
1) If the 'r' in 'rpath-link' stands for 'runtime', then the name 'rpath-link' seems misleading, because it is used at link time.
2) I already specified my library directories for link time in the 'library-path'. I see no use for 'rpath-link'. Strange reality: from http://www.kaizou.org/2015/01/linux-libraries/ I know 'library-path' is not used for secondary dependencies (a dependency from one shared library to another shared library). To resolve these secondary dependencies you need to set 'rpath' or 'rpath-link'. My question then is: what is the reason you may not use 'library-path' to also specify secondary dependencies and instead are obliged to use 'rpath-link'?

How I stumbled upon this problem

I have an executable called app which wants to use functionality from liba.so, so I linked app to liba.so. liba.so depends on libb.so. Both liba.so and libb.so reside in directory mylibs. When I wanted to build my executable I ran into the message:

/usr/bin/ld: warning: libb.so.80, needed by /.../liba.so, not found (try using -rpath or -rpath-link)

Followed by several undefined reference errors.
To properly build it I have to set both 'library-path' and 'rpath-link' (or 'rpath') to the directory mylibs. It puzzles me why 'library-path' is not also used to search for secondary dependency libb.so and that an additional 'rpath-link' must be set to search for this secondary dependency.

Related question: Rationale of -rpath-link

Courtmartial answered 1/3, 2017 at 9:50 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.