Why doesn't ld search rpaths from a DSO itself at link time

0
votes

I have libA.so, libB.so, and an executable 'foo'. 'foo' needs libB.so which itself needs libA.so. During linking foo explicitly links with libB because it directly uses symbols from it. 'foo' does not directly use symbols from libA. When linking 'foo', ld wants to check it can resolve symbols references from libB in libA but it can't find libA. I can make it find libA by using -Wl,rpath-link=, or I can have the linker ignore libA using -Wl,--allow-shlib-undefined.

The problem is I shouldn't have to set either of these options because libB.so contains an rpath that tells the linker where to find libA.so and the linker uses this rpath at runtime to successfully find libA. So why doesn't it use it at link time? Forcing foo's build configuration to know where libA is seems completely unnecessary in this case?

1
linkershared-librariesld

1 Answers

1
votes

I shouldn't have to set either of these options because libB.so contains an rpath that tells the linker where to find libA.so and the linker uses this rpath at runtime

You are mixing up the static linker ld and the runtime linker (aka loader) ld.so.

On Linux, these come from binutils and GLIBC respectively. They are completely different programs, maintained by different sets of people.

It would be possible for ld to implement the search path that current version of ld.so uses, but this is

  • nontrivial amount of code, that would need to be written from scratch and
  • will break as soon as ld.so search mechanism is changed

Update:

isn't the search of the rpath executed by the dynamic linker 'the standard'

There is no standard that defines this (that I know of).

In addition, on Linux and Solaris the search path that ld.so uses could contain dynamic tokens like $ORIGIN and $PLATFORM, which are unknown at (static) link time.