Alan DuBoff wrote:
> But if BOOST was able to compile with SunStudio, everyone could use
> libCstd.so.1 and be happy, no?
BOOST compiles with Sun Studio 12, quite nicely (modulo a few changes here and
there).
The Standard C++ Library usually consists of two components:
- a shared library
- corresponding source code files {translation units)
The shared library contains common, reusable components. which do not need to
be
compiled into the executables or libraries one builds, and can be compiled and
linked into a shared library. In this respect, it is similar to the Standard C
Library. However, the shared library does not (and cannot) contain a full
implementation of the Standard C++ Library, because the Standard C++ Library
also consists of templates and methods/functions. These
templates/methods/functions must be instantiated at compile time on the
specific
types one creates when writing an application or shared library.
The source code files contain definitions and declarations of the Standard C++
Library templates (and not only templates). These templates and methods are
compiled and linked into the binaries (executables and shared libraries) one
builds.
The shared library and the translation units/source code files are tied to each
other. So, once someone builds an app or a shared library with a certain
Version
X of the Standard C++ Library, that application or shared lib is forever tied
to
that particular version of the Library.
The problem is libCstd.so.1 which must stay backwards compatible. And because
of
libCstd.so.1's backwards compatibility requirement, the Standard C++ Library's
translation units which correspond to libCstd.so.1 must stay compatible with
the
shared library. And because of this, these translation units prevent BOOST from
compiling with Studio 12, because the implementation of the Standard C++
Library
defined by these translation units is incomplete.
As soon as libCstd.so.1 removed from the equation, one can use another
implementation of the Standard C++ Library with its two components: the shared
library, and its translation units. This works because the translation units
which ship by default with Studio 12 (and which install in
${STUDIO12_INSTALL_ROOT}/prod/include/{CC,CC/Cstd, ... }) are no longer used.
> Wouldn't this be the best situation for KDE? Yes, it would still mean
> that folks who have gcc apps running on Linux, may need to do some
> porting to Studio on Solaris/OpenSolaris, but by doing so, they create
> an ABI compatible world, and that is good IMO.
Yes, of course ABI compatibility is a goal. But in this case it is simply not
possible. In order to compile/link BOOST with Studio 12 and the Standard C++
Library in libCstd.so.1, one must modify the header files/translation units
which come with Studio. This is possible. But the consequence of doing so is
that the resulting binaries are no longer ABI compatible with libCstd.so.1.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
Stefan.Teleman at Sun.COM
