Moving from Solaris to AIX – Spectrum can assist or even do the migration for you…
The process of porting Solaris applications to the AIX environment sometimes can be accomplished with a simple recompile. However, at other times a successful port may require compilation, link changes or even code changes. Let’s examine some important considerations when migrating applications from Solaris to AIX.
Overview
Most applications are written in one or more high-level languages. Because applications written in assembly or macro assembly require complete rewrites, the whitepaper discusses porting issues primarily in terms of C and C++. Different issues may occur with other high-level languages. Java* issues are discussed in one section.
Most well-written C/C++ programs compile and run on AIX without change. Good programming practices include:
• Conformance to the ANSI/ISO C/C++ standard
• Strong consideration of portability in the design, implementation and maintenance phases of the software cycle
• Use of prototyped functions declarations throughout the code
Migrating applications from one platform to another involves recompiling, relinking, debugging, testing and, if necessary, performance-tuning. Well-written programs often port easily with few code changes when they adhere to standard language conventions and aren’t overly dependent on platform architecture.
Comparing Solaris and AIX
Developers porting applications from Solaris to AIX should be aware of the differences in files and environment variables between the two environments. For example, with Solaris, numeric value defines are located in /usr/include/sys/limits.h, but with AIX, these defines are in /usr/include/limits.h. Other differences in the areas of data type size and alignment (such as long double) are covered in the whitepaper.
Compiler options—If an application takes advantage of Solaris-specific compiler options, then changes must be made to makefiles in order to port to AIX. The whitepaper includes tables that compare Solaris and AIX compilation flags. These tables emphasize which AIX flag to use in place of a comparable Solaris flag. For example, -dryrun on Solaris shows options passed by the driver to the compiler but doesn’t perform the actual compile. The equivalent AIX option is -#. AIX compilation options that are unavailable on Solaris aren’t discussed.
Libraries and archives—On AIX, an archive may contain different types of objects. For example, libc.a contains 32- and 64-bit .o files, 32-bit shared libraries and 64-bit shared libraries. Applications (32- and 64-bit) can link dynamically and/or statically against this single archive (libc.a).
Shared objects and shared libraries—AIX and Solaris have different views of shared objects. A shared module in AIX can be an object file or an archive file member. A single shared archive library, as described, can contain multiple members—some are shared modules; others are ordinary object files. In Solaris, shared libraries are always ordinary files built from source files compiled with special options and linked in a special way. Typically in AIX, system-shared libraries are archive files, making it easier to update system libraries while minimally impacting applications.
Linking and loading—Differences in how AIX and Solaris view runtime linking are detailed in the whitepaper. Included is an example that shows how the link order of libraries on the two platforms can result in different behaviors. Obtaining the desired Solaris behavior on AIX also is covered.
Memory segments and thread programming—The 32- and 64-bit address space is described in the whitepaper. Some applications may need to be aware of, for example, which memory segments contain the 32- and 64-bit shared library data.
Threads programming—Applications that use the Solaris threads programming interface—e.g., thr_create(), mutex_lock() and cond_signal() function calls—are generally nonportable. These Solaris thread functions aren’t supported in POSIX threads:
• Daemon threads (thr_create)
• Joining any thread (Solaris allows you to join any thread with a tid 0)
• Thread suspend and thread continue
This can be an intractable porting issue if an application is tightly bound to Solaris-specific threads. General differences between the thread interfaces are discussed in the whitepaper, but information on moving to POSIX threads that are supported on AIX also is provided.
Porting Issues
Specific porting issues are covered extensively in the whitepaper, with many specific examples showing actual code, error messages and solutions. The following topics are discussed in detail:
Compiler errors—Because Sun* Microsystems’ Forte compiler is more forgiving of nonstandard constructs than IBM’s VisualAge* for C/C++ compiler, unexpected compiler errors can occur. The whitepaper describes some known errors and offers recommended solutions. For example, casting is strictly enforced by the VisualAge compiler on AIX. This means that const void * can’t be cast to any non-const pointer. Other examples and solutions are given, including those that result in compile failures. For instance, Solaris has an fstream::rdbuf().fd() method that gets a file descriptor from the fstream object. This method isn’t available on AIX.
Interprocess communication (IPC) limits—UNIX* programmers commonly use IPC mechanisms (semaphore, shared memory and message queues) to provide communication among multiple processes. On Solaris, application programmers communicate their IPC resource requirements to the system administrator who edits /etc/system and sets limits for IPC mechanisms. The problem with this method is that the higher the limits are set, the bigger the kernel gets, and the greater the chance performance can be adversely affected. However, if the limits are set too low and exceeded at runtime, the administrator must change the /etc/system values and reboot for the new values to take affect.
In contrast, on AIX, IPC limits are handled for users. The kernel has hard upper limits for IPC mechanisms and the individual IPC types are dynamically allocated/deallocated up to these upper limits. The applications always receive the maximum number of IPC resources allowed by the kernel. No editing of /etc/system is needed, and no rebooting is needed to raise the limits. The whitepaper covers this in detail.
Semaphores—Solaris supports POSIX and System V semaphore APIs. AIX only supports the System V API. Even though AIX conforms to the Unix98 standard, the POSIX real-time options are only an option under Unix98. On AIX, the semaphore.h include file in /usr/include is in place for conformance to IEEE POSIX 1003.1c only. Therefore, applications seeking functionality for these functions—sem_close(), sem_ destroy(), sem_ getvalue(), sem_init(), sem_open(), sem_post(), sem_trywait(), sem_ unlink(), sem_wait()—will compile and link cleanly but fail at runtime on AIX. Solutions for getting applications that use these unsupported APIs to run correctly are provided in the whitepaper.
« IBM Power 520 and 550 Technical Overview | Home | Port your Solaris applications to AIX 6.1 can help you reap the following benefits: »
Leave a Comment