https://sourceware.org/bugzilla/show_bug.cgi?id=26551
--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
(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.
