Effect of using the -rpath linkler option

Jonathan Wakely jwakely.gcc@gmail.com
Wed Oct 3 23:06:00 GMT 2018


On Wed, 3 Oct 2018 at 23:16, Edward Diener wrote:
>
> I am using gcc 7.2.0-19 on a Debian OS running on an arm-64 SOM. For an
> executable I am building, call it XXX, using a shared library, which I
> also build, call it YYY, I am specifying a linker option when linking
> the object files to final executable form of:
>
> '-Wl,-rpath=/some/path'

GCC just passes that through to the linker.

> so that XXX finds YYY at both linktime and runtime at /some/path.
> However after the executable is built the 'readelf' utility shows me
> that the RUNPATH is set by my -rpath setting rather than the RPATH. What
> this means is that an end-user can set an LD_LIBRARY_PATH which is
> searched before the -rpath I am setting in my executable for library
> YYY. This is not what I want.
>
> Why does the -rpath set the RUNPATH rather than the RPATH ?

This is a linker question, so nothing to do with GCC. Your linker is
configured to prefer the new RUNPATH tag instead of RPATH.

The ld.so(8) man page says usage of RPATH is deprecated. I believe
that's because there's no way to override RPATH if it's present. If
RUNPATH is used you can still override it if needed via LD_RUN_PATH.
If you don't want LD_RUN_PATH to have effect, don't set it (or unset
it) in your program's environment.

> How can I make sure that the executable finds YYY in the -rpath I want
> both at link time and run time, rather than in some possible place in
> the LD_LIBRARY_PATH ?

If you're using the GNU linker, use the linker option --disable-new-dtags



More information about the Gcc-help mailing list