C++ and OpenMP runtime libraries in Solaris
By Chris Quenelle on Feb 19, 2009
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.
Updating the libraries
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 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.
SPROtweakWe 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:
1) 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.
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.
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.