[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20535

Florian Weimer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||fweimer at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Florian Weimer  ---
Fixed in binutils 2.28.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20535

Florian Weimer  changed:

   What|Removed |Added

 CC||sdvormwa at mtu dot edu

--- Comment #7 from Florian Weimer  ---
*** Bug 16936 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20535

--- Comment #6 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Clifton :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a24bb4f0cce83eea8b2ad1542316651143af6f90

commit a24bb4f0cce83eea8b2ad1542316651143af6f90
Author: Nick Clifton 
Date:   Tue Oct 11 13:50:10 2016 +0100

Enhance objdump so that it will use .got, .plt and .plt.got section symbols
when disassembling, and it will use dynamic relocs to interpret entries in the
PLT and GOT.

binutils * objdump.c (is_significant_symbol_name): New function.
(remove_useless_symbols): Do not remove significanr symbols.
(find_symbol_for_address): If an exact match for the specified
address has not been found, try scanning the dynamic relocs to see
if one of these matches the address.  If so, use the symbol
associated with the reloc.
(objdump_print_addr_with_symbol): Do not print offsets to symbols
with no value.
(disassemble_section): Only use dynamic relocs if the user
requested this.
(disassemble_data): Always load dynamic relocs if they are
available.

ld  * ld-aarch64/emit-relocs-515-be.d: Adjust output to match change
in objdump.
* ld-aarch64/emit-relocs-515.d: Likewise.
* ld-aarch64/emit-relocs-516-be.d: Likewise.
* ld-aarch64/emit-relocs-516.d: Likewise.
* ld-aarch64/farcall-b-plt.d: Likewise.
* ld-aarch64/farcall-bl-plt.d: Likewise.
* ld-aarch64/gc-plt-relocs.d: Likewise.
* ld-aarch64/tls-desc-ie.d: Likewise.
* ld-aarch64/tls-tiny-desc.d: Likewise.
* ld-aarch64/tls-tiny-gd.d: Likewise.
* ld-aarch64/tls-tiny-ie.d: Likewise.
* ld-arm/arm-app-abs32.d: Likewise.
* ld-arm/arm-app.d: Likewise.
* ld-arm/arm-lib-plt32.d: Likewise.
* ld-arm/arm-lib.d: Likewise.
* ld-arm/armthumb-lib.d: Likewise.
* ld-arm/cortex-a8-fix-b-plt.d: Likewise.
* ld-arm/cortex-a8-fix-bcc-plt.d: Likewise.
* ld-arm/cortex-a8-fix-bl-plt.d: Likewise.
* ld-arm/cortex-a8-fix-bl-rel-plt.d: Likewise.
* ld-arm/cortex-a8-fix-blx-plt.d: Likewise.
* ld-arm/farcall-mixed-app-v5.d: Likewise.
* ld-arm/farcall-mixed-app.d: Likewise.
* ld-arm/farcall-mixed-app2.d: Likewise.
* ld-arm/farcall-mixed-lib-v4t.d: Likewise.
* ld-arm/farcall-mixed-lib.d: Likewise.
* ld-arm/ifunc-10.dd: Likewise.
* ld-arm/ifunc-14.dd: Likewise.
* ld-arm/ifunc-15.dd: Likewise.
* ld-arm/ifunc-3.dd: Likewise.
* ld-arm/ifunc-4.dd: Likewise.
* ld-arm/ifunc-9.dd: Likewise.
* ld-arm/long-plt-format.d: Likewise.
* ld-arm/mixed-app-v5.d: Likewise.
* ld-arm/mixed-app.d: Likewise.
* ld-arm/mixed-lib.d: Likewise.
* ld-arm/tls-lib-loc.d: Likewise.
* ld-cris/dso-pltdis1.d: Likewise.
* ld-cris/dso-pltdis2.d: Likewise.
* ld-cris/dso12-pltdis.d: Likewise.
* ld-elf/symbolic-func.r: Likewise.
* ld-frv/fdpic-pie-1.d: Likewise.
* ld-frv/fdpic-pie-2.d: Likewise.
* ld-frv/fdpic-pie-6.d: Likewise.
* ld-frv/fdpic-pie-7.d: Likewise.
* ld-frv/fdpic-pie-8.d: Likewise.
* ld-frv/fdpic-shared-1.d: Likewise.
* ld-frv/fdpic-shared-2.d: Likewise.
* ld-frv/fdpic-shared-3.d: Likewise.
* ld-frv/fdpic-shared-4.d: Likewise.
* ld-frv/fdpic-shared-5.d: Likewise.
* ld-frv/fdpic-shared-6.d: Likewise.
* ld-frv/fdpic-shared-7.d: Likewise.
* ld-frv/fdpic-shared-8.d: Likewise.
* ld-frv/fdpic-shared-local-2.d: Likewise.
* ld-frv/fdpic-shared-local-8.d: Likewise.
* ld-frv/fdpic-static-1.d: Likewise.
* ld-frv/fdpic-static-2.d: Likewise.
* ld-frv/fdpic-static-6.d: Likewise.
* ld-frv/fdpic-static-7.d: Likewise.
* ld-frv/fdpic-static-8.d: Likewise.
* ld-frv/tls-dynamic-2.d: Likewise.
* ld-frv/tls-initial-shared-2.d: Likewise.
* ld-frv/tls-relax-shared-2.d: Likewise.
* ld-frv/tls-shared-2.d: Likewise.
* ld-i386/plt-nacl.pd: Likewise.
* ld-i386/plt-pic-nacl.pd: Likewise.
* ld-i386/plt-pic.pd: Likewise.
* ld-i386/plt.pd: Likewise.
* ld-i386/pr19636-1d-nacl.d: Likewise.
* ld-i386/pr19636-1d.d: Likewise.
* ld-i386/pr19636-2c-nacl.d: Likewise.
* ld-i386/pr19636-2c.d: Likewise.
* ld-ifunc/ifunc-21-x86-64.d: Likewise.
* ld-ifunc/ifunc-22-x86-64.d: Likewise.
* ld-ifunc/pr17154-i386.d: Likewise.
* ld-ifunc/pr17154-x86-64.d: Likewise.
* ld-m68k/plt1-68020.d: Likewise.
* ld-m68k/plt1-cpu32.d: Likewise.
* ld-m68k/plt1-isab.d: Likewise.
* ld-m68k/plt1-isac.d: Likewise.
* ld-metag/shared.d: Likewise.
* 

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=20535

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Clifton :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=199fa1b7089d7f7438b087fa30504ea5a590f561

commit 199fa1b7089d7f7438b087fa30504ea5a590f561
Author: Nick Clifton 
Date:   Tue Oct 11 12:04:42 2016 +0100

Add support to the static linker for the tokens accepted by the dynamic
linker when resolving search paths.

PR ld/20535
* emultempl/elf32.em (_search_needed): Add support for pseudo
environment variables supported by ld.so.  Namely $ORIGIN, $LIB
and $PLATFORM.
* configure.ac: Add getauxval to list AC_CHECK_FUNCS list.
* config.in: Regenerate.
* configure: Regenerate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20535

--- Comment #4 from Nick Clifton  ---
Created attachment 9554
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9554=edit
Proposed patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[sbergman at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20535

--- Comment #2 from Stephan Bergmann  ---
(In reply to Nick Clifton from comment #1)
>   The problem here is that you are using environment variables which are not
>   being expanded at link time.

No, I'm not using environment variables.  I'm rather using the $ORIGIN token
supported by ld.so's rpath token expansion (see "man ld.so").

> > $ gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath='$ORIGIN' dso2.c -Ldsos 
> > -ldso1
> 
>   This stores a DT_NEEDED string of "$ORIGIN" into libdso2.so.  It does
> *not* 
>   store the expansion of $ORIGIN into the DT_NEEDED entry. 

I assume you mean DT_RPATH instead of DT_NEEDED?

And that this creates a DT_RPATH of exactly "$ORIGIN" is expected.

> > $ gcc -Wl,-rpath='$ORIGIN/dsos' main.c -Ldsos -ldso2
> 
>   This makes the linker look in a directory path called "$ORIGIN/dsos", again
>   with no expansion of $ORIGIN, which is why this approach also fails.  (Note
>   this behaviour is intended.  The linker does not perform expansion of 
>   environment variables found in path names).

But when ld.so supports $ORIGIN (and some more special tokens) in DT_RPATH,
wouldn't it be useful if ld did, too?

(I just notice that I failed to add "-z origin" when using
"-Wl,-rpath='$ORIGIN...", but even adding that to the two affected gcc
invocations doesn't make a difference.)

>   This sequence does work:
> 
>   % setenv ORIGIN `pwd`
>   % mkdir dsos
>   % gcc -shared -fPIC -o dsos/libdso1.so dso1.c
>   % gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath=$ORIGIN/dsos dso2.c
> -Ldsos -ldso1

That causes an absolute path be recorded into dso2's DT_RPATH, which is /not/
what is wanted.

>   % gcc main.c -Ldsos -ldso2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20535] DSO1 needed by DSO2 linked into executable not found without -rpath-link, even though DT_RPATH and -rpath would find it

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20535

Nick Clifton  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||nickc at redhat dot com
 Resolution|--- |INVALID

--- Comment #1 from Nick Clifton  ---
Hi Stephan,

  The problem here is that you are using environment variables which are not
  being expanded at link time.

> $ gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath='$ORIGIN' dso2.c -Ldsos 
> -ldso1

  This stores a DT_NEEDED string of "$ORIGIN" into libdso2.so.  It does *not* 
  store the expansion of $ORIGIN into the DT_NEEDED entry. 

> $ gcc -Wl,-rpath='$ORIGIN/dsos' main.c -Ldsos -ldso2

  This makes the linker look in a directory path called "$ORIGIN/dsos", again
  with no expansion of $ORIGIN, which is why this approach also fails.  (Note
  this behaviour is intended.  The linker does not perform expansion of 
  environment variables found in path names).

  This sequence does work:

  % setenv ORIGIN `pwd`
  % mkdir dsos
  % gcc -shared -fPIC -o dsos/libdso1.so dso1.c
  % gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath=$ORIGIN/dsos dso2.c -Ldsos
-ldso1
  % gcc main.c -Ldsos -ldso2

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils