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.