Private nullref symbol in 5.6 but not with 5.5 C++ compiler

Question

We try to use the libmtmalloc.so library with our project using LD_PRELOAD_32 environment variable:
export LD_PRELOAD_32=/usr/lib/libmtmalloc.so.1This library provides advanced memory management and memory debugging features.
We have two Solaris machines named ‘earth2’ and ‘mars’. ‘earth2’ has “CC: Sun C++ 5.6” compiler, while ‘mars’ has an older version “CC: Sun C++ 5.5”.
If we build our application on ‘earth2’ and load it with libmtmalloc.so library, it crashes inside heap memory management functions invoked from std::basic_string methods. The same application built on ‘mars’ machine runs without problems. It seems that the reason of the crash is a visibility of std::basic_string::__nullref symbol generated differently by each version of compiler. The following little code sample demonstrates the problem
main.cpp
=======
#include <string>
int main()
       std::string strA = "";
       std::string strB = "aaa";
       strA = strB;
      return 0;
}If we build this sample on both machines, we can see that each compiler provides a different visibility of std::basic_string::__nullref symbol.
On ‘earth2’ machine
===============
hsbld33BM@earth2 $ CC -V
CC: Sun C++ 5.6 2004/07/15
hsbld33BM@earth2 $ CC -v main.cpp
hsbld33BM@earth2 $ elfdump -s -C a.out | grep nullref
[3] 0x00021720 0x00000030 OBJT WEAK D 0 .data std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__nullref
[13] 0x00021718 0x00000004 OBJT WEAK D 0 .data std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__i_ctl___nullref
[56] 0x00021720 0x00000030 OBJT WEAK D 0 .data std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__nullref
[66] 0x00021718 0x00000004 OBJT WEAK D 0 .data std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__i_ctl___nullref
On ‘mars’ machine
==============
hsbld33BM@mars $ CC –V
CC: Sun C++ 5.5 2003/03/12
hsbld33BM@mars $ CC -v main.cpp
### command line files and options (expanded):
### -v main.cpp
### CC: Note: NLSPATH = /opt/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
/opt/SUNWspro/prod/bin/ccfe -y-o -ymain.o -y-fbe -y/opt/SUNWspro/prod/bin/fbe -y-xarch=generic -y-verbose -O0 -ptf /tmp/29641%1.%2 -ptx /opt/SUNWspro/prod/bin/CC -ptk "-v -xs " -D__SunOS_5_9 -D__SUNPRO_CC=0x550 -Dunix -Dsun -Dsparc -D__sparc -D__unix -D__sun -D__BUILTIN_VA_ARG_INCR -D__SVR4 -D__SUNPRO_CC_COMPAT=5 -xdbggen=no%dwarf2+stabs -y-s -xdbggen=incl -y-xmemalign=4s -I-xbuiltin -xldscope=global -instlib=/opt/SUNWspro/prod/lib/libCstd.a -I/opt/SUNWspro/prod/include/CC/Cstd -I/opt/SUNWspro/prod/include/CC -I/opt/SUNWspro/prod/include/CC/rw7 -I/opt/SUNWspro/prod/include/cc -D__SUN_PREFETCH -xcomdat -y-comdat main.cpp -s /tmp/ccfe.29641.0.s >&/tmp/ccfe.29641.1.err
rm /tmp/ccfe.29641.0.s
### CC: Note: LD_LIBRARY_PATH = (null)
### CC: Note: LD_RUN_PATH = (null)
### CC: Note: LD_OPTIONS = (null)
/usr/ccs/bin/ld -u __1cH__CimplKcplus_init6F_v_ -zld32=-S/opt/SUNWspro/prod/lib/libldstab_ws.so -zld64=-S/opt/SUNWspro/prod/lib/v9/libldstab_ws.so -zld32=-S/opt/SUNWspro/prod/lib/libCCexcept.so.1 -zld64=-S/opt/SUNWspro/prod/lib/v9/libCCexcept.so.1 -R/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib -o a.out /opt/SUNWspro/prod/lib/crti.o /opt/SUNWspro/prod/lib/CCrti.o /opt/SUNWspro/prod/lib/crt1.o /opt/SUNWspro/prod/lib/values-xa.o -Y P,/opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib:/opt/SUNWspro/prod/lib/rw7:/opt/SUNWspro/prod/lib:/usr/ccs/lib:/usr/lib main.o -lCstd -lCrun -lm -lw -lc /opt/SUNWspro/prod/lib/CCrtn.o /opt/SUNWspro/prod/lib/crtn.o >&/tmp/ld.29641.2.err
rm main.o
rm /tmp/ccfe.29641.1.err
rm /tmp/ld.29641.2.err
hsbld33BM@mars $ elfdump -s -C a.out | grep nullref
[25] 0x00021300 0x00000030 OBJT GLOB D 0 .bss std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__nullref
[92] 0x00021300 0x00000030 OBJT GLOB D 0 .bss std::basic_string<char,std::char_traits<char>,std::allocator<char> >::__nullref
We want to be able to use the libmtmalloc.so with newer compiler version. Please advise what we should do in order to achieve this goal.

Answer 1

Those old compiler versions probably still have several bugs relating to the string class. Both are End Of Life. No support will be available for C++ 5.5 after this year, and all support ends for C++ 5.6 next year.
The best solution would be to upgrade to a supported release. If you need to build or run on Solaris 8 (which is also End Of Life), get Sun Studio 11, which is free.
[http://developers.sun.com/sunstudio/products/previous/11/index.jsp]
If you don't need to build or run on anything earlier than Solaris 9, get Sun Studio 12, which is also free.
[http://developers.sun.com/sunstudio/]
"Free" means there is no license fee, no charge for downloading or use, nor for the distribution of applications created with Sun Studio.
Next, whatever compilers you wind up using, be sure to get all the current patches. At a minimum, get the patches for the C compiler, C++ compiler, the compiler "back end" (sometimes called "common components"), and the C++ runtime library. You can get all patches here:
[http://developers.sun.com/sunstudio/downloads/patches/index.jsp]
The updated C++ runtime libraries need to be installed on the build system and on all target systems.
You should also be sure that your build processes do not contribute to the problem:
1. The C++ runtime libraries must be linked dynamically (the .so versions). Static linking can cause program failures when the application consists of other shared (dynamic) libraries, or when you run on a system different from the compilation system.
2. When you build on one version of Solaris, the application can run on later versions of Solaris, but not on earlier versions.
3. When you create a binary (.o, .a, .so) using one compiler version, it can be linked into a program created by a later compiler verison, but not into a program created by an earlier compiler version. (Note: the compiler version installed on a computer should not matter, since in a properly-constructed program, there is no runtime dependency on the installed compiler.)
Information about supported compilers and interactions are listed in the Support Matrix:
[http://developers.sun.com/sunstudio/support/matrix/index.jsp]