Menu
▾
▴
#71 Crash caused by SCIM (C++ ABI problems)
closed-fixed
5
2007-06-22
2006-06-07
No
Hello!
Our product uses Eclipse Platform for GUI on Linux. We
support many OS systems and provide one binaries set
for all systems (I mean one set for each platform). For
IA32 architecture we use gcc-3.3 C++ runtime (we
provide it with our product) for all systems.
Recently we found C++ ABI problems on RedFlag 5 DC
(Asianux 2.0) - this system uses SCIM by default for
input chinese symbols.
When we start our product by starting Eclipse - it
starts GTK and GTK starts SCIM by default. After
loading SCIM immodule library
(/usr/lib/gtk-2.0/immodules/im-scim.so) our non-native
for this system runtime conflicts with SCIM library -
some C++ STL symbols from our runtime and our libraries
is bound to such symbols from im-scim.so (because
im-scim.so is loaded one of the first). It means that
im-scim.so exports its C++ STL inline symbols and such
symbol from another library can be bound to this
symbol! There is no problem in case of all libraries
use one C++ runtime, but there is a BIG problem in case
of some libraries uses another non-native runtime!
Asianux 2.0 contains SCIM-1.2.3, I installed last SCIM
1.4.4 and determined that this problem is reproduced also.
I looked to scim-bridge project which was created to
solve C++ ABI problems (as I understand). but
scim-bridge uses im-scim.so also and this problem is
reproduced using scim-bridge also!
I think SCIM should hide all C++ STL inline symbols
from all libraries which can be loaded by window
library (such GTK) because it may affect user
application compiled with another runtime.
So, you can hide your C++ STL inline symbols using
linker version-scripts
(http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html
). You may use simple script to hide all STD symbols
from library export table:
---- begin of version.script file -----
{
local:
extern "C++"
{
std::*
};
};
---- end of version.script file -----
Just modify your linker command by adding one new option:
... -Wl,-version-script,version.script ...
Thank you for your attention!
Vitaly Slobodskoy
Logged In: YES
user_id=13130
Did you ever tried --enable-ld-version-script configure
option? It's available since scim 1.4.0.
However it could only solve this issue partially. Acroread
still crashes with this option enabled. Because Acroread has
the same issue itself.
Logged In: YES
user_id=1535611
Thank you for your quick answer!
I knew nothing about this option - sorry for my oversight.
After recompiling SCIM 1.4.4 with this option our product
works perfect!
Thank you!
Logged In: YES
user_id=1535611
One more question:
Why "--enable-ld-version-script" option is disabled by
default?
Logged In: YES
user_id=13130
Because this option will cause problem on many Linux
distributions due to a bug in binutils.
Logged In: YES
user_id=1535611
Hm... Could you please refer me to request in binutils bug
tracker or give a short information about this bug?
Thanks!
Logged In: YES
user_id=13130
I don't know the bug number. Fortunately, it has been fixed
in recent binutils versions.
Logged In: YES
user_id=1535611
Sorry for my importunity...
Could you please give me the short description of this
binutils bug? What was the problem? I know nothing about
bad side of version scripts usage and it's very important
for me to know the possible problems...
Thank you for your help!
Logged In: YES
user_id=13130
The problem is: scim will simply crash if ld version script
is enabled. I don't know the detail of this issue. It was
originally reported by Fedora Core users. Hopefully it's a
specific issue of Fedora Core.
Logged In: YES
user_id=1535611
It's strange... Do you know the steps to reproduce this
bug on Fedora Core (may be, you will refer me to your bug
tracker) - I can investigate this issue...
And one more question: why do you think that this crash on
FC was caused by binutils bug?