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