[Bug ld/26551] A definition referenced by an unneeded (--as-needed) shared object should be exported
https://sourceware.org/bugzilla/show_bug.cgi?id=26551
--- Comment #11 from H.J. Lu ---
(In reply to Fangrui Song from comment #10)
> (In reply to Michael Matz from comment #9)
>
> I filed the bug not to find an alternative solution. I am wary of the
> semantics of --export-dynamic, --dynamic-list (and contributed the recent
> --export-dynamic-symbol --export-dynamic-symbol{,-list} BTW).
>
> First, this is already a problem with --allow-shlib-undefined. Now the
> question is whether it is also a problem of --no-allow-shlib-undefined. My
> reasoning is that placing a shared object on the linker command line is an
> explicit intention that its referenced symbols should be exported, even if
> the shared object itself is unneeded (in terms of --as-needed).
You want to export symbols referenced by unused shared libraries which
may be dlopened. But not all unused shared libraries will be dlopened.
I think this new behavior should be controlled by a new explicit option
if this behavior is desirable.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26551] A definition referenced by an unneeded (--as-needed) shared object should be exported
https://sourceware.org/bugzilla/show_bug.cgi?id=26551
--- Comment #10 from Fangrui Song ---
(In reply to Michael Matz from comment #9)
I filed the bug not to find an alternative solution. I am wary of the semantics
of --export-dynamic, --dynamic-list (and contributed the recent
--export-dynamic-symbol --export-dynamic-symbol{,-list} BTW).
First, this is already a problem with --allow-shlib-undefined. Now the question
is whether it is also a problem of --no-allow-shlib-undefined. My reasoning is
that placing a shared object on the linker command line is an explicit
intention that its referenced symbols should be exported, even if the shared
object itself is unneeded (in terms of --as-needed).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/26520] "objdump: DWARF error: could not find variable specification at offset ..." when generating assembly listing of .elf file containing symbols from libstdc++.a
https://sourceware.org/bugzilla/show_bug.cgi?id=26520 Frank Mehnert changed: What|Removed |Added CC||frank.mehnert at gmail dot com --- Comment #6 from Frank Mehnert --- I had the same problem and I can confirm that this change fixes my problem. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26551] A definition referenced by an unneeded (--as-needed) shared object should be exported
https://sourceware.org/bugzilla/show_bug.cgi?id=26551 --- Comment #9 from Michael Matz --- I think ld.bfd is completely fine to not export exe symbols only referenced by mentioned but not otherwise needed libraries. It's follows from traditional behaviour that executables don't export any symbols, which aren't obviously needed in a static linking model, which is why -E exists. I could a libararies that isn't necessary by anything from the executable containing a back-reference to the executable to not be obvious. If you really need to support this situation you would normally need to use -E, which btw is documented to sometime be necessary with dlopen games: -E ... If you use "dlopen" to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself. The more controled way for this is --dynamic-list. Doing what you suggest would break the following invariant: you can remove any unneeded as-needed -lxyz arguments from the link command and end up with the same binary. This is basically the set of libraries that 'ldd -u' would print, and is why as-needed was implement to start with, to save that manual manual work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26551] A definition referenced by an unneeded (--as-needed) shared object should be exported
https://sourceware.org/bugzilla/show_bug.cgi?id=26551
--- Comment #8 from H.J. Lu ---
(In reply to Fangrui Song from comment #7)
>
> >a.c < #include
> int foo() { return 42; }
> int main() {
>void *h = dlopen("./b.so", RTLD_LAZY);
>int (*bar)(void) = dlsym(h, "bar");
>return bar();
> }
> e
> >b.c < int foo();
> int bar() { return foo(); }
> e
>
> cc -fuse-ld=bfd -shared -fPIC b.c -ldl -o b.so
> cc -fuse-ld=bfd -pie -fPIE a.c -Wl,--push-state -Wl,--as-needed ./b.so
> -Wl,--pop-state -ldl
>
> ./a.out => symbol lookup error: ./b.so: undefined symbol: foo
>
> -fuse-ld=gold or -fuse-ld=lld is good.
If it is the only use case, why not use
'--dynamic-list=DYNAMIC-LIST-FILE'
Specify the name of a dynamic list file to the linker. This is
typically used when creating shared libraries to specify a list of
global symbols whose references shouldn't be bound to the
definition within the shared library, or creating dynamically
linked executables to specify a list of symbols which should be
added to the symbol table in the executable. This option is only
meaningful on ELF platforms which support shared libraries.
--
You are receiving this mail because:
You are on the CC list for the bug.
