STL clash between VTK and ITK on Solaris

...or a short story on Solaris, C++ compilers, standards, and libraries

This WIKI page has been put together because there are problems with ITK and VTK when both have to be compiled on Solaris, with Sun's compiler tool collection, a.k.a. Sun Studio.

(We'll call Sun's C++ compiler CC from now on, and the C compiler cc. GNU's compilers are also available on Solaris, Sun ships the 3.4.3 version in /usr/sfw/bin. The GNU CC compiler is called g++, whereas the C compiler is gcc.)

Comparing STLport and Cstd

Sun ships the STLport library as part of their compiler collection (Studio installs in /opt). There are a few reasons behind it, one of them being that STLport is more portable than their own STL implementation (Cstd). On the other hand, Sun does not warrant binary (ABI) compatibility with STLport's future versions. Sun, however, warrants, that Cstd is maintined in a way, that it remains compatible over the years, hence software compiled for an earlier release of Solaris, remains usable on later releases, when they are compiled/linked with Cstd.

Cstd and STLport4 libraries cannot be mixed - if one part/library of a program is linked with the stlport lib, then all other parts should be linked with it, otherwise there will be troubles.:

Quote from Sun Studio 12: C++ User's Guide:

       "STLport is binary incompatible with the default libCstd. If you use the STLport
       implementation of the standard library, then you must compile and link all files,
       including third-party libraries, with the option
       -library=stlport4."

(http://docs.sun.com/app/docs/doc/819-5267/bkakg?a=view)

Cstd has some disadvantages:

       * it is ancient - this Stl implementation was given to Sun (maybe bought by Sun) back in around 1997 from Rouge Wave. 
       * Hence it lacks later C++ features (they were sacrificed for warranted compatibility),
       * even a quite large subset of the C++ standard is missing from it.

This is why Sun introduced and begun to ship the STLport4 library: it is somewhat more standards compliant.

But STLport4 has some disadvantages too:

     * it is NOT supported/maintained by Sun, so that future versions may have compatibility problems
     * ABI compatibility is NOT guaranteed. (throughout versions)
     * While is more standards compliant, this implementation still misses parts/features of the C++ ISO standard.
     * STLport4 has not been maintained over the years, and slowly became out-of-date.
     * STLport4 is not part of the OS distribution, it is part of the compiler collection, so software that uses (links with) has to package this library too.
     * Sun even states that this library may not be shipped in the future.

Links that discuss some of these issues can be found here:

http://developers.sun.com/sunstudio/documentation/ss12u1/mr/READMEs/c++_faq.html#LibComp

http://docs.sun.com/app/docs/doc/820-7599/bkakg?l=en&a=view

There is yet another doc that compares libCstd and STLport from a programmatical point of view at developers.sun.com:

"Comparing C++ Standard Libraries libCstd and libstlport" by Mukesh Kapoor, Sun Studio Development Engineering, Sun Microsystems, May 17, 2006

http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html

The case of VTK and ITK

One of the cases when both have to be compiled is the compilation of the medical imaging application 3D Slicer.

The main problem is as follows:

ITK is set to compile with the STLport4 library on Solaris, when compiled with Studio. VTK, on the contrary, is set to compile with Sun's own implementation of STL, the Cstd library.

Both libraries have advantages, and both softwares have their good reasons to set the mandatory compile libraries/flags.

gcc cannot be used to compile the toolchain (ie. Slicer's toolchain) on Solaris anymore, since VTK does not support the compilation with gcc (see this mail on VTK's mailing list:

http://www.vtk.org/pipermail/vtkusers/2009-August/102167.html), but, as they suggest in that mail, the platform-specific compiler is the best option to use.

There are more reasons to link with -stlport4 in case of ITK.

One being that Cstd lacks some methods:

http://www.itk.org/mailman/private/insight-developers/2009-April/012111.html

(and the follow up mails)

Some other reason to use the STLport library is the use some vxl/vnl symbols:

http://www.itk.org/mailman/private/insight-developers/2009-April/012118.html

and

http://www.itk.org/mailman/private/insight-developers/2009-April/012119.html

the related check-in:

http://public.kitware.com/cgi-bin/viewcvs.cgi/CMakeLists.txt?revision=1.329&root=Insight&view=markup&pathrev=ITK-3-16

For even more reasons, see Luis' mail from a few days later (and the follow-ups, if interested):

http://www.itk.org/mailman/private/insight-developers/2009-April/012132.html

http://www.itk.org/mailman/private/insight-developers/2009-April/012135.html

The summary of changes that led to the use of the stlport4 flag can be found here:

http://www.itk.org/mailman/private/insight-developers/2009-April/012151.html

All these make ITK "Cstd-incompatible".

VTK has other reasons to link mandatory with Cstd: Java.

It is stated in

http://public.kitware.com/cgi-bin/viewcvs.cgi/CMake/vtkDetermineCompilerFlags.cmake?revision=1.1&view=markup

that Ctsd is needed in order to:

       [...]
       # make sure Crun is linked in with the native compiler, it is
       # not used by default for shared libraries and is required for
       # things like java to work.
       [...]

When compiling VTK and ITK with the default settings on Solaris, with Studio, we get similar errors:

       [...]
       ld: warning: symbol `std::codecvt<wchar_t,char,__mbstate_t>::__vtbl' has differing sizes:
       (file /opt/SUNWspro/lib/amd64/libCstd.so value=0x60; file /opt/SUNWspro/lib/stlport4/amd64/libstlport.so value=0x50);
       /opt/SUNWspro/lib/amd64/libCstd.so definition taken
       [...]

This issue has already been raised both on VTK's and ITK's mailing lists, with no responses:

http://www.vtk.org/pipermail/vtkusers/2009-August/102220.html

http://www.itk.org/mailman/private/insight-developers/2009-August/013223.html

The same mail sent to the Slicer-developers list:

http://massmail.spl.harvard.edu/pipermail/slicer-devel/2009/003393.html

While no direct response from there too, still the issue has been recognized, and it even has been discussed at a Tcon in August 2009:

http://www.na-mic.org/Wiki/index.php/Engineering:TCON_2009#2009-08-13

On the other hand, Java - at least on a fairly recent Solaris 10 release, and on OpenSolaris - does not seem to be linked, or use symbols from Cstd:

       $java -version
       java version "1.6.0_15"
       Java(TM) SE Runtime Environment (build 1.6.0_15-b03)
       Java HotSpot(TM) Server VM (build 14.1-b02, mixed mode)
       $uname -a
       SunOS orlprint 5.11 snv_125 i86pc i386 i86xpv
       $ldd /bin/java
               libthread.so.1 =>        /lib/libthread.so.1
               libjli.so =>     /usr/jdk/instances/jdk1.6.0/bin/../jre/lib/i386/jli/libjli.so
               libdl.so.1 =>    /lib/libdl.so.1
               libc.so.1 =>     /lib/libc.so.1
               libm.so.2 =>     /lib/libm.so.2

...and neither of those five libs are linked with neither Crun nor Cstd. The same can be found on S10U7 and java version "1.5.0_17".

According to one Sun developer (Stefan Teleman - thanks Stefan! :)), no symbols from Cstd can be found in Java.

On the other hand, when that part of that file is commented out, VTK compiles just as fine with stlport4, so those lines do not seem to be necessary.

This might indicate that STLport is the way to go on Solaris. But if we consider the following:

   * STLport is NOT supported by Sun
   * it does NOT assure binary (or ABI) compatiby
   * is NOT maintained (so it is a bit out-of-date)
   * while more standards compliant than Cstd, still LACKS some parts of the C++ standard
   * NOT part of the core OS distribution, so one needs the library itself, or the Compiler collection
   * and it is even stated that this lib may even be removed in the future

than we can clearly see that the use of this library might only be a "temporary" solution.

Fortunately Sun has recognized this situation as well.

Apache STDCXX in later Solaris releases

In late 2009 the Apache C++ Standard Library (STDCXX) (http://stdcxx.apache.org/) has been incorporated into the Solaris OS. This move (and the decision itself) is a long process inside Sun. Such decisions are made by Architecture Review Committee, or ARC. This review process makes sure that the most possible issues are discussed in detail by the responsible engineers, so that future support, OS developments, and maintenance of such included software is taken care of, and future impact of the change is carefully considered (possible ABI changes, for example).

The documents, and related discussions are available for the public too:

http://arc.opensolaris.org/caselog/PSARC/2008/549/

While this is a new development in Solaris, based on the above procedure, this library is there to stay for years. It is already present in newer OpenSolaris releases (since about Nov 2009), and it may even be backported into Solaris 10 at some later Update.

On the other hand, this library can be built for the needed platform in case it's not present. (See one example in this forum thread: http://opensolaris.org/jive/thread.jspa?messageID=397004 )

Stdcxx4 has several advantages over both Cstd, and STLport:

   * it resides in /usr/lib, so it is part of the OS, not the compiler collection
   * is fully standards compliant (STL_clash_between_VTK_and_ITK_on_Solaris#Standards_compliance_of_the_Apache_C.2B.2B_Standard_Library)
   * will be supported by Sun (it could not be in /usr/lib without support)
   * will be maintained in the future
   * MULTIPLATFORM: this library exists (or can easily be compiled) on multiple platforms, and this can cut development time and costs.

Apache's stdcxx is supported by the Studio 12 (CC 5.9) and Studio 12.1 (CC 5.10) compilers (compiler collections). Support is somewhat simpler in case of Studio 12.1.

Excerpt from the man page of stdcxx4:

(SunOS 5.11 Last change: 07 July 2009 Apache Standard C++ Library libstdcxx4(3lib) )

Sun Studio 12:

CPPFLAGS = `pkg-config --cflags-only-I libstdcxx4`

CXXFLAGS = `pkg-config --cflags-only-other libstdcxx4`

LDFLAGS = `pkg-config --libs libstdcxx4`

Sun Studio 12 Update 1:

CXXFLAGS = -library=stdcxx4

LDFLAGS = -library=stdcxx4

---

Based on the above, considering Apache STDCXX in place of STLport4 - at least on Solaris - could be a preferable option. This way we might lose backward compatibility (not necessarily, as STDCXX could be built as part of the build process), but the softwares could be more "future-proof".

Maybe multiplatform development can benefit from this transition as well.

Current state of the Slicer3 build process

See: http://www.orl.szote.u-szeged.hu/~attila/build.process.curent.state.html

---

Standards compliance of the Apache C++ Standard Library

Here is part of the man page for stdcxx4 from Solaris

(SunOS 5.11 Last change: 07 July 2009 Apache Standard C++ Library libstdcxx4(3lib) )

The Apache C++ Standard Library implements sections 17 through 27 and Annexes C, D, and E of the C++ Standard. The C++ Standard contains the following libraries:

The Language support library

The Diagnostics library

The General utilities library

The Strings library

The Localization library

The Containers library

The Iterators library

The Algorithms library

The Numerics library

The Input/Output library

Standards Conformance

This implementation of the C++ Standard Library conforms to ISO/IEC 14882:2003 -- International Standard for Information Systems -- Programming Language C++. In addition, this implementation conforms to a subset of the requirements of the following standards:

In some cases, this implementation of the C++ Standard Library provides extensions to enhance functionality and usability. These extensions are highlighted in the HTML documentation where they occur.

ISO/IEC 9899 Programming languages -- C

ISO/IEC 10967-1 Information technology -- Language independent arithmetic -- Part 1: Integer and floating point arithmetic

ISO/IEC 10646-1 Information technology -- Universal Multiple-Octet Coded Character Set (UCS)

ISO/IEC 559 (same as IEEE 754) Binary floating-point arithmetic for microprocessor systems

ISO/IEC 9945-1 (same as IEEE Std 1003.1) Information technology -- Portable Operating System Interface (POSIX)

ISO 8601 Data elements and interchange formats -- Information interchange -- Representation of dates and times

ISO/IEC 8859-1 through -7 Information technology -- 8- bit single-byte coded graphic character sets -- Parts 1 - 7

ISO/IEC 2022 Information technology -- Character code structure and extension techniques