There is a set of runtime libraries that are maintained by the compiler
team, and delivered to Solaris so they can be made available in
/usr/lib on all Solaris systems. The ones most likely to affect people
are the OpenMP support library (libmtsk) and the C++ runtime libraries
(libCstd, libCrun). What makes these libraries special is that they
share interfaces with the compilers. The compilers implement language
features by automatically inserting function calls to these libraries.
This means that new features in the compilers can require new versions
of these libraries to be installed in /usr/lib.
The long-standing process for this is that users are
expected to install the latest runtime library patches when they want
to use a new release of the compilers, or when they want to run
executables that were built with the latest release of the compiler.
This procedure has some problems.
1) The lead time, from last bug fix, to getting a Solaris patch
available on sunsolve.com can be several months. The compiler team
never knows when the last bug will be fixed in a compiler release, and
they don't know if that bug will require a library fix or not.
2) Hunting down the right runtime library patches, and installing them
on all the machines that need them requires significant time and system
Note: On Linux, we always have to
include our own copies of the runtime libraries. That's an added
complication, but I'm discussing the problems related to skew between
the compilers and the Solaris installation, and on Linux there is never
We lived with these difficulties when our releases were 12-18 months
apart, but we've been doing more frequent Express releases for several
years now, and so we've been relying more and more on a workaround.
Internally, we call that workaround SPROtweak after the name of the
package that implements it. The SPROtweak package contains copies of
all runtime libraries that the compiler team delivers to Solaris. We
install this package inside the compiler install directory when we want
that compiler to override the system library versions. Our current
policy is to install SPROtweak for Express releases, but not for FCS
releases. This workaround also has several problems:
Programs built with Express compilers depend on the compiler
installation directory. If you run the executable on a different
computer, it will try to fall back to the system libraries, but it may
not work correctly.
2) Official Solaris patches to support
Express releases may or may not be available in a timely fashion, so
executables are only moderately portable to different Solaris hosts.
We use this workaround as a crutch inside Sun. We commonly install the
SPROtweak package even in FCS versions of the compilers inside Sun,
because we don't want our users to have to install patches. Since the
compilers inside Sun are often used from an NFS mounted directory, we
can usually avoid version skew. But we're essentially saying that we
don't want to deal with patches, but we're willing to make end users
deal with patches.
Sometimes we make a distinction between
casual users and production users. The internal installations of the
compilers are for casual users, so we don't want to make them deal with
patches. Production users will normally be expected to have their own
installation of the tools, and have closer control over the patch
levels of their build machines. Production users will have a sys-admin
to maintain their build machines. This side-steps the issue of the many
casual users that don't work for Sun.
Are there any better solutions?
A) Always include the latest runtime libraries inside the compiler
directory, and give users a simple command line option to use the
system libraries or the local copies when creating an executable. This
is fairly straightforward, but it doesn't go very far towards creating
a seamless solution.
B) Fix the Solaris patch process
so it takes less time to get these fixes available in Solaris. This
would make the situation on OpenSolaris pretty good, because
availability is 99% of the problem. Updating the runtime libraries is
much simpler (although you still have root permissions). But the
situation on Solaris 10 is only half addressed, because it's still a
PITA to install the patches.
I'd be interested in hearing the different ways that "version skew" is dealt with on Linux.
In the long run, the way we will address this skew may be different on
OpenSolaris and on Solaris 10 because the distribution mechanism is