C++ and OpenMP runtime libraries in Solaris
Thoughts on developer tools.

All | Dbx | Development Tools | Life in General | OpenSolaris | plus | Software Philosophy | Sun Studio

fav comics

« command-not-found... | Main | Blog relocation »
20090219 Thursday February 19, 2009

C++ and OpenMP runtime libraries in Solaris

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.

SPROtweak

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:

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.

GCC?

I'd be interested in hearing the different ways that "version skew" is dealt with on Linux.

Future

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.


Posted by Chris Quenelle ( Feb 19 2009, 04:43:12 PM PST ) - Permalink - -

Comments:

Post a Comment:

Comments are closed for this entry.

Older blog entries:

mug shot Chris Quenelle is a tools developer at Sun Microsystems. He's worked on performance and debugging tools at Sun for more than 10 years. He reads comic books and science fiction, and has more tivos than he can keep track of.

Calendar

« October 2009
SunMonTueWedThuFriSat
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
       
Today

RSS Feeds

XML
All
/Dbx
/Development Tools
/Life in General
/OpenSolaris
/plus
/Software Philosophy
/Sun Studio

Search

Links

Navigation

Referers

Today's Page Hits: 231