Runtime stlport4 error: Unexpected Signal : 11

Question

Hi Gurus,
I am using CC 5.5 with stlport4 to build our project. I basically build a jni library which got called from java class. I had no compile and link problem. If do "ldd -r MyLib.so", all symbols are resolved. But at runtime, I got the following error:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xEFD7FF84
Function=__1cDstdGlocale2t5B6Mrk1_v_+0xC
Library=/opt/SUNWspro/lib/stlport4/libstlport.so.1
Current Java thread:
at com.ss.sp.MyLogStream.initialize(Native Method)
Platform: Solaris 2.8
SUNW CC: 5.5, compiler option -library=stlport4, -mt
JDK: 1.4.2
Thanks
Ivan

Answer 1

Sun C++ 5.5. comes with STLport as an optional standard library. SInce it is not the default version of the standard library, you must follow these rules when using it:
Every CC command line used to build the entire program must have the option -library=stlport4
Every CC command used to link any part of the program, including shared libraries, must have the option -library=stlport4
If ld is used directly (instead of CC) to link a program or shared library, it must link libstlport.so.1, and not link to libCstd.so.1.
You cannot mix program parts using the default libCstd with program parts using stlport4. The entire program, including shared libraries, must use the same standard library -- either libCstd or stlport.
You can see whether there is any conflict between libCstd and stlport in your program by running the ldd command on every executable program and every shared library. If any of these shows a dependency on libCstd.so.1, you cannot use stlport in other parts of the code.
Unfortunately, it is possible to link libCstd statically, and it's difficult to tell whether that happened if all you have is an a.out or a library. Let's hope that is not the case. The supplier of the third-party components you are using should document whether they used stlport or libCstd. If they used stlport, it needs to be the version that comes with the compiler, not a version they acquired from the stlport web site. Different versions of stlport from the web site are not binary compatibie. The versions we ship with our compilers are compatible with each other.
The remaining issue is order of initialization of shared libraries. If (for example) a C program dlopens a C++ shared library that was not built with the correct dependencies, it is possible that the shared library will try to use stlport objects that haven't been initialized yet. If the main program is a C++ program that has a dependency on stlport , you won't run into that problem. Using ldd to check the dependencies of the main programs and shared libraries will show you if dependencies are inconsistent.
It is also possible for shared libraries to be mutually dependent, so that each library requires the other library to be initialized first. (This is a programming error.) That situation should not be possible with stlport, since it should not have any dependency on any user library. But if user libraries A and B have this circular dependency, it is possible that one of them passes a bad reference to stlport. Let's consider this scenario unlikely for now. The other major issues I outlined should be investigated first.
In particular, find out from the 3rd-party vendor how they built their C++ code. The possible good answers are
1 They used the default libCstd.so.1
2. They used the libstdport.so.1 that came with the compiler.
(You can run ldd to find out these answers.)
In case 1, you cannot use stlport. You must use the default libCstd, and link it dynamically (which is the default).
In case 2, you can use stlport, and you must link it dynamically (which is the default).
Any other answer is very bad news.