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.
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 administration skills.
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 any skew.
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:
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.
3) 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.
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 different.