https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66902

            Bug ID: 66902
           Summary: _S_debug_messages is unneccessary public
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: persgray at gmail dot com
  Target Milestone: ---

Created attachment 36000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36000&action=edit
proposed patch

The _S_debug_messages array is defined in libstdc++-v3/src/c++11/debug.cc
without "static" modifier, therefore becoming exported one. But it isn't used
in GCC anywhere outside the debug.cc source module. I found no users installed
in my laptop running many KDE-, GTK- and console-based programs.

On the other side, size of _S_debug_messages differs in different versions of
libstdc++. This way, while libstdc++ 4.9 is ABI-compatible with libstdc++ 4.2,
this particular symbol causes warnings from ld.so (at least here on OpenBSD).
Yes, libstdc++ versions are "mixed": some software requires decent versions of
GCC and doesn't build on the base one (4.2.1); therefore, such software gets
built and linked with GCC 4.9 (as of now), and libstdc++ 4.9 is forced to be
searched for symbols before libstdc++ 4.2. This works in general, but there is
a nasty warning produced:

WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program

This happens because _S_debug_messages contains different number of strings in
different libstdc++ versions.

Since there is no real reason to keep _S_debug_messages public, I propose
making it static. There is an interface for accessing this array:

  const _Error_formatter&
  _Error_formatter::_M_message(_Debug_msg_id __id) const
  { return this->_M_message(_S_debug_messages[__id]); }

So the lack of "static" keyword looks like a simple overlook problem.

The attached patch simply adds "static" keyword. I've been running with this
patch for many weeks without any problem on OpenBSD/amd64.

Reply via email to