https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-11-21
CC| |redi at gcc dot gnu.org
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't remember anything concerning this exact symbol, the set of changes has
been done because some symbols that weren't present in the original gcc 3.4.0
release's libstdc++.so.6 were added later on into the GLIBCXX_3.4 symbol
version by mistake, so the changes ensured those symbols stayed as
compatibility symbols in that symver and were added (usually?) into
GLIBCXX_3.4.5 symbol version for default linking.
This particular symbol has been present already in the original 3.4.0 release:
readelf -Wa libstdc++.so.6.0.0 | grep
_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv
00000000001d7a50 00000b0600000007 R_X86_64_JUMP_SLOT 000000000008b680
_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv + 0
2822: 000000000008b680 104 FUNC WEAK DEFAULT 11
_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv@@GLIBCXX_3.4
as proven from an old rpm I found in RHEL repo. Strangely, that symbol isn't
even mentioned in the I think latest patch submission:
https://gcc.gnu.org/ml/gcc-patches/2005-06/msg01476.html
and appared probably in between that posting and the final commit in r101125 .
So, I'd say removing that GLIBCXX_3.4.6 reference to that symbol should be
fine, but will defer that to libstdc++ maintainers.
