[Bug libstdc++/88125] New: Erroneous duplicate "basic_stringbuf" symbol entry in libstdc++ gnu.ver file.

["brooks at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.