https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to nsz from comment #12)
> (In reply to Jonathan Wakely from comment #10)
> > This should fix it:
> >
> > --- a/libstdc++-v3/config/abi/pre/gnu.ver
> > +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> > @@ -58,9 +58,7 @@ GLIBCXX_3.4 {
> > # std::basic_stringbuf
> > # std::basic_stringstream;
> > std::basic_[t-z]*;
> > - std::ba[t-z]*;
> > - std::b[b-z]*;
> > - std::c[a-g]*;
> > + std::cerr;
> > # std::char_traits;
> > # std::c[i-z]*;
> > std::c[i-n]*;
> >
>
> the patch looks good, please apply it.
I think I'll just replace the std::c[a-g]* one for now.
> i guess it should be backported too, so new binutils
> keeps linking libstdc++ as expected.
Yes, I think it's safe to do so. I searched all the baseline_symbols.txt files
and only std::cerr matches any of those patterns.
I wonder if it's even worth adding a special case to binutils to
> > IMHO it's a bad idea to have such greedy patterns in the base GLIBCXX_3.4
> > version anyway, because we never want them to match new symbols, only the
> > ones that already exist in GLIBCXX_3.4
>
> then this file could be cleaned up further.
Oh definitely. I've created PR 83893 to track that (and noted some history
there).
