[Bug ld/25315] `__tcf_0' referenced in section `.rodata._ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev.cst4' of mode_query_balls_distances.o: defined in discarded section `.text.__tcf_0[_ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev]' of mode_query_balls_dis

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25315

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
The R_PARISC_DIR21L and R_PARISC_DIR14R relocs on the following:
        ldil LR'.LC34,%r28
        ldo RR'.LC34(%r28),%r28
ought to mark .rodata._ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev.cst4
against garbage collection in gc_mark_hook.  Then the R_PARISC_PLABEL32 on
        .word   P%__tcf_0
ought to mark the section where __tcf_0 is defined.  This will happen for local
symbols too.  There isn't anything special about hppa in this regard.

Very likely you have multiple
.text.__tcf_0[_ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev] sections
that aren't exact duplicates, at least one of which doesn't have __tcf_0
defined, and that particular section happens to be kept.  Check all the object
files involved in the link paying attention to sections defining __tcf_0, and
all copies of
.text.__tcf_0[_ZNK6common26ChainResidueAtomDescriptor3strB5cxx11Ev].  If you
find differences then you have some sort of code gen problem, or even a source
code problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.