RFC: Documenting Linux specific behaviour of --rpath and --rpath-link

Message ID 3ee3ef82-7096-af28-a763-6fe4ba04e7cc@redhat.com
State New
Headers show
Series
  • RFC: Documenting Linux specific behaviour of --rpath and --rpath-link
Related show

Commit Message

Luis Machado via Binutils April 7, 2021, 1:34 p.m.
Hi Guys,

   I recently had to look over a bug report about the linker not honouring
   the --rpath and --rpath-link options properly.  It was skipping one
   shared library in favour of another further on in the search path.  It
   turns out however that this is actually the correct behaviour - for Linux
   systems only, and only only under specific circumstances.  So I have put
   together the attached patch to update the linker documentation.  To save
   time, and provide context, here is what the new text would look like, if
   the patch were applied:

   '-rpath-link=DIR'
      When using ELF or SunOS, one shared library may require another.
      This happens when an 'ld -shared' link includes a shared library as
      one of the input files.

  [...]

     The linker uses the following search paths to locate required
      shared libraries:

        1. Any directories specified by '-rpath-link' options.
        2. Any directories specified by '-rpath' options.  The difference

   [...]

       10. Any directories specifed by a 'SEARCH_DIR' command in the
           linker script being used.

   [Begin new text]

      Note however on Linux based systems there is an additional caveat:
      If the '--as-needed' option is active _and_ a shared library is
      located which would normally satisfy the search _and_ this library
      does not have DT_NEEDED tag for 'libc.so' _and_ there is a shared
      library later on in the set of search directories which also
      satisfies the search _and_ this second shared library does have a
      DT_NEEDED tag for 'libc.so' _then_ the second library will be
      selected instead of the first.

   [End new text]


I thought about trying to add an explanation of why this behaviour is
mandated, but I felt that I was getting out of my depth at that point.

So - does anyone have any comment or corrections for this new text ?

Cheers
   Nick

Comments

Hans-Peter Nilsson April 9, 2021, 11:54 p.m. | #1
On Wed, 7 Apr 2021, Nick Clifton via Binutils wrote:
>   [Begin new text]

>

>      Note however on Linux based systems there is an additional caveat:

>      If the '--as-needed' option is active _and_ a shared library is

>      located which would normally satisfy the search _and_ this library

>      does not have DT_NEEDED tag for 'libc.so' _and_ there is a shared

>      library later on in the set of search directories which also

>      satisfies the search _and_ this second shared library does have a

>      DT_NEEDED tag for 'libc.so' _then_ the second library will be

>      selected instead of the first.

>

>   [End new text]

>

>

> I thought about trying to add an explanation of why this behaviour is

> mandated, but I felt that I was getting out of my depth at that point.


Swimming or diving or asking for sufficient assistance is not an
option?  1/2 :)

> So - does anyone have any comment or corrections for this new text ?


This looks sufficiently weird that someone's insanity is in
question.  Is it me?  Isn't it actually a bug swept under the
rug because of "compability"?

brgds, H-P
Fangrui Song April 10, 2021, 12:15 a.m. | #2
On 2021-04-09, Hans-Peter Nilsson wrote:
>On Wed, 7 Apr 2021, Nick Clifton via Binutils wrote:

>>   [Begin new text]

>>

>>      Note however on Linux based systems there is an additional caveat:

>>      If the '--as-needed' option is active _and_ a shared library is

>>      located which would normally satisfy the search _and_ this library

>>      does not have DT_NEEDED tag for 'libc.so' _and_ there is a shared

>>      library later on in the set of search directories which also

>>      satisfies the search _and_ this second shared library does have a

>>      DT_NEEDED tag for 'libc.so' _then_ the second library will be

>>      selected instead of the first.

>>

>>   [End new text]

>>

>>

>> I thought about trying to add an explanation of why this behaviour is

>> mandated, but I felt that I was getting out of my depth at that point.

>

>Swimming or diving or asking for sufficient assistance is not an

>option?  1/2 :)

>

>> So - does anyone have any comment or corrections for this new text ?

>

>This looks sufficiently weird that someone's insanity is in

>question.  Is it me?  Isn't it actually a bug swept under the

>rug because of "compability"?

>

>brgds, H-P


The long conjunction clauses ... do make it feel like a weird
compatibility workaround which should be dropped somehow..

In gold and ld.lld, -rpath-link is simply ignored.
Hans-Peter Nilsson April 10, 2021, 9:42 a.m. | #3
On Fri, 9 Apr 2021, Fangrui Song wrote:
> On 2021-04-09, Hans-Peter Nilsson wrote:

> > On Wed, 7 Apr 2021, Nick Clifton via Binutils wrote:

> > >   [Begin new text]

> > >

> > >      Note however on Linux based systems there is an additional caveat:

> > >      If the '--as-needed' option is active _and_ a shared library is

> > >      located which would normally satisfy the search _and_ this library

> > >      does not have DT_NEEDED tag for 'libc.so' _and_ there is a shared

> > >      library later on in the set of search directories which also

> > >      satisfies the search _and_ this second shared library does have a

> > >      DT_NEEDED tag for 'libc.so' _then_ the second library will be

> > >      selected instead of the first.

> > >

> > >   [End new text]

> > >

> > >

> > > I thought about trying to add an explanation of why this behaviour is

> > > mandated, but I felt that I was getting out of my depth at that point.

> >

> > Swimming or diving or asking for sufficient assistance is not an

> > option?  1/2 :)

> >

> > > So - does anyone have any comment or corrections for this new text ?

> >

> > This looks sufficiently weird that someone's insanity is in

> > question.  Is it me?  Isn't it actually a bug swept under the

> > rug because of "compability"?

> >

> > brgds, H-P

>

> The long conjunction clauses ... do make it feel like a weird

> compatibility workaround which should be dropped somehow..

>

> In gold and ld.lld, -rpath-link is simply ignored.


I hope you don't mean that last sentence literally, because that
sounds like a separate bug, but a more trivial one: you'd just
not see some DSOs when linking.

brgds, H-P

Patch

diff --git a/ld/ld.texi b/ld/ld.texi
index 6d016ecc347..73f5917db17 100644
--- a/ld/ld.texi
+++ b/ld/ld.texi
@@ -2323,8 +2323,19 @@  Any directories specifed by a @code{SEARCH_DIR} command in the
 linker script being used.
 @end enumerate
 
+Note however on Linux based systems there is an additional caveat:  If
+the @option{--as-needed} option is active @emph{and} a shared library
+is located which would normally satisfy the search @emph{and} this
+library does not have DT_NEEDED tag for @file{libc.so}
+@emph{and} there is a shared library later on in the set of search
+directories which also satisfies the search @emph{and}
+this second shared library does have a DT_NEEDED tag for
+@file{libc.so} @emph{then} the second library will be selected instead
+of the first.
+
 If the required shared library is not found, the linker will issue a
 warning and continue with the link.
+
 @end ifset
 
 @kindex -shared