When I build the scim-1.4.6 packages on Solaris Nevada build 66 with SunStudio 12 (or 11) and CBE 1.6. I found gtk-query-immodules-2.0 would core after loading im-scim.so. In dbx, it reports "no mapping at the fault address", as following:
signal SEGV (no mapping at the fault address) in __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,__rwstd::__select1st<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<std::pair<const std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > >::begin at line 741 in file "tree"
It's really a nightmare to tell what's wrong from the error message 
I thought it's a STL problem at the beginning.
It took me 1 day to find the real reason, which is fairly simple: the static object instance initializations are not in proper order.
In im-scim.so, there is a static
object instance, and it calls a global function in libscim-1.0.so, in
that global function, it accesses another static object instance which is not initialized yet. I
wrote a small test program, it just uses dlopen() to load im-scim.so. From
the debugger, I could see, the static constructor in im-scim.so is
called before the static constructor in libscim-1.0.so. Therefore, the test
program cores. I don't know if it is a bug of libCrun or ld.so?
I also asked this question in SunStudio C++ forum as well as [osol-tools-linking]. Here is an workaround patch, please note, it leaves an un-finalized heap object, __config_repository, so your configuration may not be saved.
P.S., when I am using snv_62, the shared objects works fine, but failed on snv_66.
