[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 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- 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 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=18652 -- 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 #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 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.
[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 #7 from Fangrui Song ---
(In reply to H.J. Lu from comment #6)
> (In reply to Fangrui Song from comment #5)
> > ld.bfd a.o --as-needed b.so
> >
> > Let a.o define a function which will be called by b.so via dlopen. In this
> > case, ld should export the function. This justification may look weak but I
> > think it is moving toward the right direction if we consider that GNU ld
> > from binutils 2.22 defaulted to --no-copy-dt-needed-entries (doing less
> > shared object traversal for more proper dependency tracking and avoiding
> > unneeded work).
>
> LD creates dynamic section only if dynamic relocation is needed.
> For this test, since no dynamic relocation is needed, there is no
> dynamic section. Since there is no dynamic section, there is no
> dynamic symbol table.
>a.c <
int foo() { return 42; }
int main() {
void *h = dlopen("./b.so", RTLD_LAZY);
int (*bar)(void) = dlsym(h, "bar");
return bar();
}
e
>b.c < symbol lookup error: ./b.so: undefined symbol: foo
-fuse-ld=gold or -fuse-ld=lld is good.
--
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 #6 from H.J. Lu --- (In reply to Fangrui Song from comment #5) > ld.bfd a.o --as-needed b.so > > Let a.o define a function which will be called by b.so via dlopen. In this > case, ld should export the function. This justification may look weak but I > think it is moving toward the right direction if we consider that GNU ld > from binutils 2.22 defaulted to --no-copy-dt-needed-entries (doing less > shared object traversal for more proper dependency tracking and avoiding > unneeded work). LD creates dynamic section only if dynamic relocation is needed. For this test, since no dynamic relocation is needed, there is no dynamic section. Since there is no dynamic section, there is no dynamic symbol table. -- 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 Fangrui Song changed: What|Removed |Added CC||matz at suse dot de, ||mliska at suse dot cz -- 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 #5 from Fangrui Song --- ld.bfd a.o --as-needed b.so Let a.o define a function which will be called by b.so via dlopen. In this case, ld should export the function. This justification may look weak but I think it is moving toward the right direction if we consider that GNU ld from binutils 2.22 defaulted to --no-copy-dt-needed-entries (doing less shared object traversal for more proper dependency tracking and avoiding unneeded 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 #4 from H.J. Lu --- I have a patch. But I need a run-time test without--allow-shlib-undefined to justify it. -- 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 #3 from Fangrui Song --- When --as-needed is in action, a shared object is added as a DT_NEEDED tag if it satisfies a non-weak undefined reference from a regular object (surviving under --gc-sections). This is the main use case of the option. Apparently in GNU ld, --as-needed is also used to decide whether a definition needs to be exported. I think it'd be good if this task can be detached from --as-needed (like gold). For an "unneeded" (in terms of --as-needed) shared object, it may be loaded by other shared objects. Adding the shared object on the command line is an explicit intention that the "unneeded" (unneeded by the executable, but may be needed by other shared objects) may require some definitions to be exported. (The definitions may be statically known (by transitive loading of shared objects; the behavior is related to --copy-dt-needed-entries) or dynamic (dlopen).) -- 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 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-08-29 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- For ld.bfd a.o --as-needed b.so -o bfd.unneeded since there is no DT_NEEDED tag, no dynamic section is created. -- 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 #1 from H.J. Lu --- --allow-shlib-undefined is a separate issue. Do you have a run-time testcase without --allow-shlib-undefined. -- 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 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
