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

Reply via email to