https://sourceware.org/bugzilla/show_bug.cgi?id=26407
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|WAITING |RESOLVED
--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Fabian Vogt from comment #6)
> (In reply to H.J. Lu from comment #4)
> > '--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.
> >
> > So symbols aren't on the dynamic list will be bound to the definition
> > within the shared library. The linker behavior matches the linker
> > manual.
>
> That doesn't explain the behaviour change with -Bsymbolic-functions and the
> different behaviour with gold.
Let focus on ld. -Bsymbolic-functions changes behavior is a bug, which has
been fixed in 2.35.
> The definition of the symbol is inside lib.so, so there is no reason this
> shouldn't work.
?
> This breaks because the break binary has a R_X86_64_COPY relocation, which
> essentially moves the symbol out of the lib into the executable.
>
> IMO copy relocations are an implementation detail which should be made as
> compatible as possible, in this case maybe by making --dynamic-list-data the
> default if --dynamic-list is passed.
There is no different between value and setValue as far as --dynamic-list
is concerned. Linker provides precise controls with command-line options.
You need to tell linker exactly what you need.
--
You are receiving this mail because:
You are on the CC list for the bug.
