Can DT_RUNPATH replace DT_RPATH?

[H.J. Lu]

Hi,

The current gABI says "One object's DT_RUNPATH entry does not affect the
search for any other object's dependencies." But there is no such wording
for DT_RPATH in the previous gABI. In glibc, one object's DT_RPATH applies
to all objects it loads. We can't replace DT_RPATH with DT_RUNPATH
since DT_RUNPATH doesn't provide the same functionality as DT_RPATH.


--
H.J.

[Alan Modra]

I thought the whole point of DT_RUNPATH was the difference you cite
above. In other words, when an application and its libraries all use
DT_RUNPATH rather than DT_RPATH, then a library can specify the search
path for its dependencies without being affected by any other search
path.

--
Alan Modra
Australia Development Lab, IBM

[Suprateeka Hegde]

And that when both exist, only DT_RUNPATH should be honored by the
dynamic linker.

What is the requirement to replace DT_RPATH?

--
Supra

[Rod Evans]

>>> The current gABI says "One object's DT_RUNPATH entry does not affect the
>>> search for any other object's dependencies." But there is no such
>>> wording
>>> for DT_RPATH in the previous gABI. In glibc, one object's DT_RPATH
>>> applies
>>> to all objects it loads. We can't replace DT_RPATH with DT_RUNPATH
>>> since DT_RUNPATH doesn't provide the same functionality as DT_RPATH.

My recollection is that DT_RPATH was the original (AT&T) definition, and it
only applied to the object that contained it, and affected the search for the
dependencies of that object.

But, there were differences with the interaction of LD_LIBRARY_PATH.
On Linux the order was DT_RPATH, LD_LIBRARY_PATH, defaults. On
Solaris the order was LD_LIBRARY_PATH, DT_RPATH, defaults. We
always thought the environment variable should override.

DT_RUNPATH was invented to define the Solaris search order. On
Solaris DT_RPATH and DT_RUNPATH are treated as the same.

Maybe there were other subtleties I've long forgotten about.


--
----
Rod.