http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52188
Bug #: 52188
Summary: [4.7 regression] IPA-CP change broke libstdc++ symbol
versioning on Solaris
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: jamb...@gcc.gnu.org, paolo.carl...@oracle.com
Host: *-*-solaris2*
Target: *-*-solaris2.*
Build: *-*-solaris2.*
As already discussed to some length in
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01163.html
the following patch
2011-07-18 Martin Jambor <mjam...@suse.cz>
* ipa-prop.h: Include alloc-pool.h, all sorts of updates to general
comments.
(ipcp_values_pool): Declare.
(ipcp_sources_pool): Likewise.
[...]
caused libstdc++.so symbol versioning to be broken on Solaris. Before the
patch,
when compiling locale-const.cc only contains references and definitions of
_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv.constprop.36
After the patch, the same source has references to
_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv
The latter is matched by the linker map and exported at version GLIBCXX_3.4.15,
which is effectively closed with the release of gcc 4.6 where the symbol wasn't
present.
To avoid breaking symbol versioning on Solaris, the question is what to do
here:
we obviously cannot export it at 3.4.15, but could instead export it at
3.4.17 *on Solaris* instead. Before going that route, I need to make certain
that this isn't just a code generation accident and the symbol can vanish again
later: the exported interface of a shared object *must not* depend on the
vagaries of code generation changes.
Martin?
