[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] New: 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

Bug ID: 20535
   Summary: DSO1 needed by DSO2 linked into executable not found
without -rpath-link, even though DT_RPATH and -rpath
would find it
   Product: binutils
   Version: 2.26
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with binutils-2.26.1-1.fc24.x86_64,

> $ cat dso1.c
> void fun1(void) {}
>
> $ cat dso2.c
> void fun1(void);
> void fun2(void) { fun1(); }
>
> $ cat main.c
> void fun2(void);
> int main(void) {
>  fun2();
>  return 0;
> }
>
> $ mkdir dsos
> $ gcc -shared -fPIC -o dsos/libdso1.so dso1.c
> $ gcc -shared -fPIC -o dsos/libdso2.so -Wl,-rpath='$ORIGIN' dso2.c -Ldsos 
> -ldso1
> $ gcc -Wl,-rpath='$ORIGIN/dsos' main.c -Ldsos -ldso2
> /usr/bin/ld: warning: libdso1.so, needed by dsos/libdso2.so, not found (try 
> using -rpath or -rpath-link)
> dsos/libdso2.so: undefined reference to `fun1'
> collect2: error: ld returned 1 exit status

fails to find libdso2.so needed by libdso1.so, even though (a) libdso1.so has a
DT_NEEDED $ORIGIN (so it should be found via point 6 below), and (b) the ld
command line for building a.out contains -rpath='$ORIGIN/dsos' (so it should
already be found via point 2 below).

The ld man page claims (under -rpath-link) that:

  "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 between
-rpath and -rpath-link is that directories specified by -rpath options are
included in the executable and used at runtime, whereas the -rpath-link option
is only effective at link time. Searching -rpath in this way is only supported
by native linkers and cross linkers which have been configured with the
--with-sysroot option.

  [...]

  "6.  For a native ELF linker, the directories in 'DT_RUNPATH' or 'DT_RPATH'
of a shared library are searched for shared libraries needed by it. The
'DT_RPATH' entries are ignored if 'DT_RUNPATH' entries exist."

  [...]

Adding -Wl,-rpath-link=dsos when building a.out would help, but its not clear
to me why that should be necessary.

-- 
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/13406] version script: please allow anonymous tag to be combined with other tags

[sbergman at redhat dot com]

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

--- Comment #9 from Stephan Bergmann  ---
(The original problem had been solved in LibreOffice with

"fdo#42865: privatized unique empty string symbol," i.e., adding
_ZNSs4_Rep20_S_empty_rep_storageE to the version maps in a section named
GLIBCXX_3.4, the same section libstdc++ weakly exports it in.)

-- 
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 gold/16100] shared lib exports definition of _ZdlPv even though local per --version-script

[sbergman at redhat dot com]

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

--- Comment #2 from Stephan Bergmann sbergman at redhat dot com ---
Still broken for me with current binutils git trunk:

(Switched alternatives back to use /usr/bin/ld.bfd.)  Built
~/binutils/trunk/inst/bin/ld.gold --version GNU gold (GNU Binutils
2.24.51.20131031) 1.11.

  $ g++ -shared -fPIC -o lib1.so lib1.cc
  $ g++ -shared -fPIC -c lib2.cc
  $ g++ -### -shared -fPIC -o lib2.so -Wl,--version-script,lib2.ver lib2.o -L.
-l1
  # replacing collect2 in the linker command line:
  $ ~/binutils/trunk/inst/bin/ld.gold --build-id --no-add-needed --eh-frame-hdr
--hash-style=gnu -m elf_x86_64 -shared -o lib2.so
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/crtbeginS.o -L.
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.2
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../..
--version-script lib2.ver lib2.o -l1 -lstdc++ -lm -lgcc_s -lc -lgcc_s
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/crtendS.o
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/../../../../lib64/crtn.o
  $ nm lib2.so | grep _ZdlPv
  0698 T _ZdlPv

-- 
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 gold/16100] New: shared lib exports definition of _ZdlPv even though local per --version-script

[sbergman at redhat dot com]

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

Bug ID: 16100
   Summary: shared lib exports definition of _ZdlPv even though
local per --version-script
   Product: binutils
   Version: 2.23
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ian at airs dot com
  Reporter: sbergman at redhat dot com
CC: ccoutant at google dot com

I can reproduce this at least on Fedora 19 (binutils-2.23.52.0.1-9.fc19.x86_64)
but it reportedly also hits GNU gold (GNU Binutils; openSUSE 12.3 2.23.1)
1.11.

With lib1.cc containing:

  void test1(char * p) { delete p; }

and lib2.cc containing:

  void operator delete(void *) throw() {}
  extern C void test2() {}

and lib2.ver containing:

  {
  global:
test2;
  local:
*;
  };

When switching alternatives to use /usr/bin/ld.gold:

  $ g++ -shared -fPIC -o lib1.so lib1.cc
  $ g++ -shared -fPIC -o lib2.so -Wl,--version-script,lib2.ver lib2.cc -L. -l1
  $ nm lib2.so | grep _ZdlPv
  0698 T _ZdlPv

shows that the operator delete(void *) replacement function is exported from
lib2.so even though the version script demotes it to local.  Doing the above
with /usr/bin/ld.bfd results in local

  05e8 t _ZdlPv

-- 
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/15167] ld merges gnu_unique def and normal ref into normal symbol

[sbergman at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15167

Stephan Bergmann sbergman at redhat dot com changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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