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.
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.
> 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.
scim-bridge has been included in scim-1.4.4-11 for testing.
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.
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
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.
scim-bridge has been imported into Core development (for fc6).
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
Latest RHEL5 trees include scim-bridge{-gtk}-0.4.5-2.fc6
*** Bug 217868 has been marked as a duplicate of this bug. ***