Bug 185693 - Rewrite SCIM gtkimmodule in C and eliminate libstdc++so7
Rewrite SCIM gtkimmodule in C and eliminate libstdc++so7
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: scim (Show other bugs)
5.0
All Linux
high Severity high
: ---
: ---
Assigned To: Jens Petersen
Daniel Riek
: i18n, Reopened
: 217868 (view as bug list)
Depends On: 194202
Blocks: 171491 FC6Blocker SCIM 182538
  Show dependency treegraph
 
Reported: 2006-03-16 17:20 EST by Warren Togami
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-30 21:07:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2006-03-16 17:20:56 EST
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.
Comment 1 Benjamin Kosnik 2006-03-17 14:22:20 EST
A couple of things:

1) The ideal solution would be to rewrite the GTK+ immodule in pure C.
Note this has been rejected by the SCIM maintainers. See their mailing list.

2) "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."  This paints too bleak a
picture, IMHO. This isn't some casual one-off: it is the next C++ ABI. SCIM just
happens to be using it early (with success, I might add.) It is up in the air
when this will become the standard C++ ABI, but I don't anticipate this being
too long a wait. I consider libstdc++so7 supported within Red Hat, just not so
outside of Red Hat.

3) "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." Not
really: this is work we are doing already. Even if SCIM wasn't using it, I would
like libstdc++so7 to be in RHEL5, as we need a way to experiment with the C++
ABI without causing major disruptions in stable packages.

4)  "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." I'm
willing to help fix this. Note, some of these issues would go away if
libstdc++so7 and libstdc++ packages were merged, which will happen at some point
 with 100% certainty.
Comment 2 Warren Togami 2006-03-19 12:25:24 EST
> 1) The ideal solution would be to rewrite the GTK+ immodule in pure C.
> Note this has been rejected by the SCIM maintainers. See their mailing list.

Not entirely.  Discussion continues behind the scenes, and there is also the
chance that scim-bridge will become useful.

The concern about libstdc++so7 maintenance came from Elena.  Probably best to
talk with her about this situation.
Comment 3 Jens Petersen 2006-03-31 05:14:38 EST
scim-bridge has been included in scim-1.4.4-11 for testing.
Comment 4 Lawrence Lim 2006-04-27 23:19:33 EDT
I did scim-bridge works pretty decently with scim-bridge-0.1.6-15. Will open new
bugs against scim-bridge if anything strange happen.
Comment 5 Warren Togami 2006-05-22 13:15:16 EDT
Note that scim-bridge is now included in rawhide heading towards FC6, but it is
by no means done.  Further work is necessary in order to fix its bugs to make it
suitable for FC6.  See the SCIM bug tracker for details.

https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=SCIM
Comment 6 Jens Petersen 2006-06-05 23:03:03 EDT
Re-opening to track addition of scim-bridge to Core,
since scim-bridge was moved out of the scim package to Extras
as an independent package so that it could be submitted to Core as
a separate package.
Comment 9 Jens Petersen 2006-06-06 22:55:36 EDT
scim-bridge has been imported into Core development (for fc6).
Comment 11 Lawrence Lim 2006-07-30 21:07:34 EDT
Confirmed the availability of scim-bridge in Core and also available as
component under FC and RHEL in BZ.

scim-bridge-gtkimm-0.2.6-1.fc6
scim-bridge-0.2.6-1.fc6
Comment 12 Jay Turner 2006-09-22 00:33:29 EDT
Latest RHEL5 trees include

scim-bridge{-gtk}-0.4.5-2.fc6
Comment 13 Jens Petersen 2006-11-30 22:42:17 EST
*** Bug 217868 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.