New Video on Solaris Studio and Solaris 11 Express
By vtatkar on Nov 17, 2010
Don Kretsch and I talk to Rick Ramsey about Solaris Studio. The parallel event that I presented Studio at was LISA 2010 where Solaris 11 Express was introduced in a full-day summit to SysAdmins (you can find all the slides here) . Don and I talk about optimizing for Oracle Sun systems, being the compiler/tool of choice for a significant part of Oracle stack (DB, Peoplesoft, Siebel, JD Edwards, Hyperion, Java, NetBeans are all built using Studio) and how Studio uses and supports Solaris 11 Express features.
Rick was particularly fascinated about the Application Binary Compatibility Guarantee that Studio + Solaris help to deliver, so we spent quite a bit of time on it. Its unique in the industry that binaries built on several previous releases of Solaris (from Solaris 2.6 and up) and with Studio compilers, will continue to run on newer versions of Solaris. Not only is that invaluable in quickly getting the applications requalified on a new platform- like Solaris 11 Express- but it also provides for a gentler migration path in upgrading to newer version of the OS and/or compilers. The C ABI, of course, hasnt changed since SVR4 adoption and the C++ ABI hasnt changed since the ANSI C++ standard was adopted/ratified. [Good news is that its not likely that the new standard will require incompatibilities to be introduced]
I wanted to add this bit, because of some confusion wrt what constitutes an ABI (as in the comment below, or at least my interpretation of it).
For C++, the guarantee is that if you use the earlier versions of the Sun (Studio) C++ compiler and earlier versions of Solaris, you can mix that code with later versions of the Sun Studio C++ compiler and later versions of Solaris.
eg. you compile a library with Sun Studio 8 on Solaris 8; you can link that library into applications compiled with Sun Studio 12.2 (latest) and Solaris 11 Express (latest).
For Sun Studio, ABI is a combination of compiler and stdlib. For this reason, Sun has not upgraded the default stdlib (still based on Roguewave stdlib2.0.1). This means some features are missing, but it guarantees that applications will continue to work in an upward compatible fashion. In order to offer new features, we recommend STLport4 and the latest Apache Stdlib (STLport4 is part of the compiler release, you can use -library=stlport4 to get to it; in the case of Apache, its in the repository and/or companion CD). Thus users have to make a call: build for compatibility using old library or use the latest features and not have compatible binaries. Most corporate customers and ISVs prefer to stick to the compatible solution. Which is the default.