Developing on the New Solaris Platform While Supporting Older Versions

Print-friendly Version

Introduction

How can you balance the needs of developers who want to use new Sun technologies while supporting your customer base, many with older technologies? This article describes a proven method to allow application software developers to use the latest version of the Solaris Operating Environment (OE) (as well as new Sun hardware that might require it) while supporting previous versions of the Solaris OE.

Problem Description

Frequently, independent software vendors (ISVs) have to support a variety of versions of Solaris software because many of their customers have not yet upgraded to the latest version. To allow us to make this discussion version-independent, let's refer to the latest version of the Solaris OE as "SolarisNew" and an older version as "SolarisOld".

To keep their applications working under SolarisOld, the ISVs have to run SolarisOld themselves, or so the conventional wisdom goes. The Solaris OE is guaranteed to be binary upward compatible, but not downward compatible. Indeed, if you compile and link a program under SolarisNew, it will most likely fail to run properly under SolarisOld.

On the other hand, developers want to use SolarisNew because it gives them access to various improvements, new tools (or versions of tools) and faster hardware that are not available with SolarisOld.

This situation exists with any two versions of the Solaris platform, whether it be Solaris 2.6 and Solaris 8 or Solaris 8 and Solaris 9, which is scheduled for upcoming release. How can an application developer work with SolarisNew such that their applications will work properly when deployed on customers' SolarisOld-based servers and/or workstations?

For example, let's say an ISV has application developers using the Solaris OE and an integration group that builds the software which is shipped to customers. Developers go through the code-test-debug cycle, creating local development builds several times a day. While developers are working on their piece of the application creating object files (*.o), they link against other object files or libraries that are accessible via an NFS-mounted development build server that is common to both developers and integration engineers.

After iterations of the code-test-debug cycle, developers submit their locally-tested error-free code into a common source tree. The integration group builds the official binaries (those that are shipped to customers) using that tree.

To be able to support both SolarisNew and SolarisOld platforms, there are two traditional options that ISVs may follow:

1. Both the developers and the integration group must run the same version of the Solaris OE, SolarisOld. This is the lowest-common-denominator approach that works because of the upward compatibility that the Solaris platform guarantees. The disadvantage is that your developers are stuck with SolarisOld and are unable to take advantage of the latest hardware and software.
   
   
2. The ISV maintains two different object file and library trees, one for SolarisOld and another one for SolarisNew. The developers use the SolarisNew tree, while the integration group builds the final product using the SolarisOld tree. The main disadvantage here is the additional workload and resources necessary to maintain two parallel source trees.

Neither of the above options is satisfactory.

Solution

The solution is based on the fact that you do not really need to build the application under SolarisNew and run it under SolarisOld. Instead, you can build portions of it under both versions and combine the resulting object files when needed.

The following three-step solution provides details on how an ISV could set this up.

1. Install SolarisNew on all developer machines while keeping SolarisOld on the integration build systems. Developers compile their object files on SolarisNew and then link with SolarisOld-based object and archive library files. The resulting binaries will work on SolarisNew, due to forward compatibility, but will not work under SolarisOld.
   
   
2. Next, developers perform their code-test-debug cycles on SolarisNew and then check in their source into the single source tree.
   
   
3. The integration group continues to build and test the product under SolarisOld, ensuring that the shipped binaries will run under SolarisOld and all newer versions of the Solaris platform.

Using this method, ISV developers can enjoy all the benefits of using the latest version of the Solaris OE (including new hardware) as well as support customers who use the older versions.

In a certain sense, this new method is not very different from the first traditional one cited earlier, which has both the developer team and the integration team using SolarisOld. Even in that case, no two systems are exactly the same. There are always differences in the Solaris update levels, patches, graphics devices, middleware software versions, and the like.

The Fine Print

The method described above will work correctly if you follow a few simple rules.

1. The solution assumes that your application does not use any of the system interfaces available in SolarisNew, but not available in SolarisOld. If you break this condition, the Integration group will find out quickly enough because they will not be able to link the application under SolarisOld.
   
   
2. If you use C++, you must ensure you use the same Application Binary Interfaces (ABIs) both under SolarisNew and SolarisOld. If you use Sun C++ compiler 5.0 or later, all binaries should be built either with -compat=4 or without it. You also have to use the same version of the iostream and other C++ libraries. This requirement is necessary for any application using C++, not only for using this method.
   
   
3. If your application uses X/Motif, you may need to perform a few changes to your make files. The changes described below are specific to the Solaris 2.6 to Solaris 8 combination, although similar steps may be required for other versions. The reason for these changes is that there was an incompatible Motif change between Solaris 2.6 and Solaris 8. For compatibility, Solaris 8 provides old Motif header files and libraries but you must instruct the compiler and linker to use them.

   Here are the two changes you need to make:

   • Add -DMOTIF12_HEADERS to every compile line. This is necessary because Solaris 8 uses Motif 2.1 while Solaris 2.6 uses Motif 1.2.x. Adding -DMOTIF12_HEADERS instructs the compiler to use the old Motif 1.2.x headers.
     
     
   • Under Solaris 8, use -lXm12 and -lMrm12 on the link line instead of -lXm and -lMrm. If the same make files are to be used under both Solaris 2.6 and Solaris 8, a better method is to replace -lXm and -lMrm with /usr/dt/lib/libXm.so.3 and /usr/dt/lib/libMrm.so.3, respectively. This way, the linking will work equally well under either version of the Solaris platform.
     
     
4. Your application should use dynamic linking for system libraries such as /usr/lib/libc.so.1. This requirement has been around for quite a long time and most applications today already satisfy it. In fact, newer versions of the Solaris platform don't even have the old static versions of the system libraries.
   
   
5. Verify that your application is Solaris ABI-compliant using the appcert tool, which is freely available from Sun. The method described in this article will work correctly if your application uses only documented Solaris interfaces.

Performing the appcert check regularly is a very good idea regardless of whether you use the method described in this article or not. Only ABI-compliant applications using dynamic linking for system libraries are guaranteed to provide upward binary compatibility.

In summary, this method allows application developers to enjoy the best Sun tools and systems available while ensuring a broad deployment of their applications, including the customers who are not running the latest version of Solaris software.

It has been submitted for official documentation via the Sun RFE (Request For Enhancement) process. You can reference this by RFE 4444438 "Enabling ISVs to develop on new Solaris version using old .o files.").

This method has been successfully used in the field by at least one large ISV, where it has worked quite well.

About the Author

Greg Nakhimovsky is a member of technical staff at Sun Microsystems. He works with independent software vendors making sure their applications run well on Sun systems. He has over 20 years of industry experience developing, performance tuning, and troubleshooting technical computer applications.

January 2002