Bug 185693

libstdc++so7-4.2.0-0.3.20060203.2
# rpm -ql libstdc++so7
/usr/lib/libstdc++-20060203.so.7
/usr/lib/libstdc++-20060203.so.7.0.0

Currently FC5 contains this independent copy of an experimental C++ library.  It
was needed because it is currently the only solution for Bug #166041.  SCIM
requires linking to libstdc++so7 for its "weak symbol versioning" capability, in
order to avoid the C++ library conflict problem.  We cannot backport "weak
symbol versioning" to our regular libstdc++ because it breaks the C++ ABI. 
libstdc++so7 is a snapshot of an upstream branch that contains C++ ABI breaking
features.

This libstdc++so7 is allowing SCIM to work very well today in FC5, however it is
not desirable for RHEL5 for a few reasons.

- Only SCIM is supposed to link to libstdc++so7.  Despite marking and
documenting libstdc++so7 "DO NOT USE", it is possible that customers and users
will use it anyway.
- libstdc++so7 is guaranteed to break ABI and change its so-version because it
is an upstream snapshot of the C++ library.  It is a work in progress, and
upstream plans for it are currently undecided. 
- While Benjamin Kosnik has agreed to maintain this package into the future of
RHEL5, this creates a maintenance burden on him and/or the tools team.

GTK+ IMM Abstraction Problem
============================
The current necessity of libstdc++so7's "weak symbol versioning" capability
stems from an architectural problem in the way SCIM interfaces with the GTK+
immodule interface.

/usr/lib/gtk-2.0/immodules/im-scim.so
libscim-1.0.so.8 => /usr/lib/libscim-1.0.so.8 (0x00934000)
libscim-x11utils-1.0.so.8 => /usr/lib/libscim-x11utils-1.0.so.8 (0x00884000)
libstdc++-20060203.so.7 => /usr/lib/libstdc++-20060203.so.7 (0x00b02000

im-scim.so loads in a GTK+ process and provides an interface to the IM software
running in another process.  im-scim.so currently communicates over a socket to
a SCIM daemon running as the same user.  This is problematic because both the
im-scim.so immodule and SCIM user daemon are linked to libstdc++ and libscim*
libraries.  This is an architectural design problem of poor abstraction.

Ideal Solution
==============
The ideal solution would be to rewrite the GTK+ immodule in pure C.  This
requires some reorganization of SCIM code to properly abstract all events across
the communication socket rather than rely on the same scim libraries on both sides.

Upstream SCIM currently has an alpha quality "scim-bridge" in development.  It
however needs serious help and attention from more developers and testers in
order to make it feature complete and stable.  It is also possible that the
design of scim-bridge is not sound.  Further study is required before a
direction is chosen for sure.

In summary, a solution that involves a pure C GTK+ immodule is the ideal for RHEL5.

Fallback Solution
=================
If a pure C SCIM GTK+ immodule cannot be written and stabilized in time, then
the current libstdc++so7 method is a working however undesirable way to ship RHEL5.

If the ideal solution is not possible by RHEL5, then Bug #182177 must be fixed
instead.