Description of problem:
When updating to scim-libs-1.4.4-9.3.fc5, the RPM post scriptlet fails with:

Cannot load module /usr/lib64/gtk-2.0/immodules/im-scim.so:
/usr/lib64/libscim-x11utils-1.0.so.8: undefined symbol:
_ZNSt11_7_200604288ios_base4InitC1Ev


Version-Release number of selected component (if applicable):
scim-libs-1.4.4-9.3.fc5.x86_64

How reproducible:
always

Steps to Reproduce:
1. rpm -e scim-libs
2. rpm -i fedora/core/updates/5/x86_64/scim-libs-1.4.4-9.3.fc5.x86_64.rpm

Actual results:
Cannot load module /usr/lib64/gtk-2.0/immodules/im-scim.so:
/usr/lib64/libscim-x11utils-1.0.so.8: undefined symbol:
_ZNSt11_7_200604288ios_base4InitC1Ev
/usr/lib64/gtk-2.0/immodules/im-scim.so does not export GTK+ IM module API:
/usr/lib64/libscim-x11utils-1.0.so.8: undefined symbol:
_ZNSt11_7_200604288ios_base4InitC1Ev


Expected results:
update-gtk-immodules to succeed.

Additional info:
Passing the missing symbol "_ZNSt11_7_200604288ios_base4InitC1Ev" through
c++filt, I get "std::_7_20060428::ios_base::Init::Init()", which presumably is
provided by libstd++.so.7.

The last working version is "scim-libs-1.4.4-9.2.fc5.x86_64"
Comparing the contents, I see that it links against libstdc++.so.7:
 ldd scim-libs-1.4.4-9.2.fc5/usr/lib64/libscim-x11utils-1.0.so.8 | grep stdc++
        libstdc++-20060428.so.7 => /usr/lib64/libstdc++-20060428.so.7
(0x00002aaaaaed5000)

While "1.4.4-9.3" links with libstdc++.so.6:
ldd scim-libs-1.4.4-9.3.fc5/usr/lib64/libscim-x11utils-1.0.so.8 | grep stdc++
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaaacd7000)

I'm personally curious as to why you guys decided to link with libstdc++.so.7 in
the first place.