https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125
Bug ID: 88125 Summary: Erroneous duplicate "basic_stringbuf" symbol entry in libstdc++ gnu.ver file. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: brooks at gcc dot gnu.org Target Milestone: --- We've been working on getting libstdc++ to link correctly with LLD, and came across a problematic duplicate entry in the gnu.ver symbol version file. Normally, one would only expect to find two entries for the same symbol in the gnu.ver symbol file when there are corresponding asm ".symver" aliases in the source files. And, for most of the duplicate entries, there are ".symver" aliases, and the world is fine. (Well, almost fine. Gold has an Internal Error about the matter, but that's https://sourceware.org/bugzilla/show_bug.cgi?id=21215 and not relevant here...) Anyway, there is one exception to that: _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv on lines 359 and 1152: https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/abi/pre/gnu.ver?revision=266242&view=markup#l359 https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/abi/pre/gnu.ver?revision=266242&view=markup#l1152 As far as I can find, there are no corresponding entries for these symbol versions in the sources. So: ld.bfd happily handles these in a "first match wins" way, and only emits the "3.4" version for the symbol. We can see this in the baseline_symbols.txt file from the libstdc++-abi tests -- there's only one entry: https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt?revision=261865&view=markup#l482 (By contrast, there are of course multiple entries for the other symbols that are properly multi-versioned. See, e.g., lines 268/269.) LLD, however, points out the problem and errors out. We can see that this bug was actually present in the patch that initially added the "3.4.6" version of this symbol: https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=101125 Although this patch adds the entry for this symbol at 3.4.6 in the gnu.ver file (then called linker-map.gnu), it doesn't add any corresponding entries to the baseline_symbols.txt files for it. Thus, I believe the correct solution here is to simply remove the second entry for _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv; (lines 1151 to 1153) from the gnu.ver file. Since it is being ignored by ld.bfd, this won't cause any ABI or exported-symbol changes.