https://sourceware.org/bugzilla/show_bug.cgi?id=18652
Alan Modra amodra at gmail dot com changed:
What|Removed |Added
CC||amodra at gmail dot com
Summary|--no-allow-shlib-undefined |--no-allow-shlib-undefined
|stopped policing explicit |affects loading of
|mention of all dependencies |DT_NEEDED shared libraries
--- Comment #1 from Alan Modra amodra at gmail dot com ---
The patch was a deliberate change, with the rationale being that whether or not
a shared library was loaded to satisfy the DT_NEEDED entry of some other
library, should not depend on what sort of output ld is generating. (At least,
the underlying options that control loading of shared libraries shouldn't have
their behaviour modified if an option is explicitly given. Having different
default options depending on output is a different story.)
As a side-effect, the change made
ld --no-allow-shlib-undefined
ld -shared --no-allow-shlib-undefined
ld -pie --no-allow-shlib-undefined
all behave the same with respect to reporting undefined symbol errors in shared
libraries. The option --no-allow-shlib-undefined is about input shared
libraries, just as --no-undefined is about input regular object files, so I
think being consistent here is also good.
However, what I did in making
--allow-shlib-undefined/--no-allow-shlib-undefined affect loading of DT_NEEDED
shared libraries is quite suspect. It certainly would be more logical to make
--copy-dt-needed-entries/--no-copy-dt-needed-entries the only controlling
option over loading DT_NEEDED shared libraries.
So I'm not going to mark the bug invalid as you feared, but it may end up as
WONTFIX if the fix is too disruptive..
--
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
