https://sourceware.org/bugzilla/show_bug.cgi?id=16693
--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Cary Coutant from comment #9) > > --dynamic-list isn't used to control which symbols are exported or > > not. From ld manual: > > > > '--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. > > True, but a necessary side effect of not binding a symbol within the > library is exporting it via the dynamic symbol table. This option is > commonly used to ensure specific symbols are exported (it's basically > -Bsymbolic with a list of exceptions), but it doesn't *remove* any of > the locally-bound symbols from the dynamic symbol table. The > --exclude-libs option does that for symbols defined in the named > libraries, but also prevents symbols in the dynamic list from being > added. That, I think, is a bug. When building shared library, --dynamic-list doesn't change the dynamic symbol table, i.e., ld -shared --dynamic-list ... and ld -shared ... generate the same dynamic symbol table. From this point of view, ld -shared --exclude-libs=ALL --dynamic-list ... and ld -shared --exclude-libs=ALL ... generate the same dynamic symbol table isn't a bug. -- 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