Binary (in)Compatibility PDF Print E-mail
User Rating: / 3
PoorBest 
Written by Michael Felt   

There is a new POWER chip - and consequently there is a lot of discussion about binary (in)compatibility. What causes of binary incompatibility and how might be avoided? A short explanation of this is covered here.

With new hardware, operating systems etc. there is a frequent concern about application portability. We all have some experience with this phenomenon. Unsure? How about the last time you updated the operating system on a PC, or bought a new PC and reinstalled your old programs?

Introduction

With modern operating systems binary incompatibility is most often caused by application design or programming development decisions and much less often caused by operating system changes. A classic example of when binary incompatibilty was a major complaint of long-term customers was when Digital came out with the Alpha processor. A fantastic processor, far ahead of others at the time - but all the old programs - often applications AND data needed to be updated. In other words, all applications needed to be recompiled, or purchased again and data often needed to be converted from one layout to another. Conversion can be a major headache.

Recently many organizations are switching to Linux - as a more generic, hardware independent platform. Often there is a binary incompatibility requiring a conversion process. Many organizations are moving not only from one operating system to Linux, but also from an "old" hardware platform to an Intel™ or POWER™ processor. These experiences, or concerns  of conversion headaches, cause many organizations to delay a move to something new for a long time. Are the concerns warrented? Maybe. Much depends on the organization making the change as well as the track record of the new operating system (update) and/or hardware supplier or vendor.

AIX, Solaris, HPUX, Linux, etc. are all doing there best to ensure that programs that run well on a current version of the operating system will continue to operate well on a newer version. Often, the reverse (new to old version of operating system) is generally not supported - it is hard to run unmodified when dependent on features that were preent in a previous version. Note: HPUX, Solaris, AIX, True64, etc. are not Linux. Some conversion is to be expected when moving from anything to Linux simply because the features and system calls are different.

What is the most likely cause of binary incompatibility for a program compiled or ported to AIX?

For 32-bit programs AIX is binary compatible from "way back when" (AIX 3.2.5) to now (AIX 5.3) when certain conventions are followed. IBM has a reference page on AIX binary compatibility and application portability. However, this is not true for all programs. The most likely cause of binary compatibility is using static libraries (storing the library instruction code in the application with the program) rather than shared libraries.

If stored (i.e. not shared) libraries are the most likely cause of binary incompatiblity - why don't all programs use shared libraries?

The most obvious advantage of having non-shared, or linked libraries (to use yet another name for a stored or static library) is that you dont have to have the library already installed to use the program. The program might even load faster. And many feel it makes you less susecptible to changes in the underlying operating systems. Another reason some developers prefer using static libraries is because of a specific modification they want to make. And lastly, many developers consider it much easier to support a package using static libraries because they control all the code.

Why might a program using a shared library not be compatible?

A shared library often functions as an API - or Application Programming Interface. As long as changes in a library are only internal to the library and/or the way the library communicates with other underlying layers the applicaiton continues to run unmodified. In other words, as long as there is no change that requires a modification in the way(s) an application built on an API uses the API then the modifications are "transparent".

If AIX has such a long track record of binary compatibility why are though so many packages in the AIX Toolbox, or other open source packages, pre-compiled for AIX 4.3.3, AIX 5.1, AIX 5.2 and/or AIX 5.3?

This impossible to answer with simple "because". There are too many possible factors to be absolutely certain, but I can make a best guess! Between AIX 4.3.3 and AIX 5.1 there was Project Monteray. During that time period there was a so-called "Early Adopter" version of AIX (AIX 5.0 was the official name - is case you ever wondered why AIX seems to have gone from version 4.3.3 to AIX 5.1). One of the apparent changes to AIX to support Linux applications occured in the C runtime libraries. There are small, but significant differences in the Linux and AIX (or UNIX) runtime environments expected by an application. And other, again small but significant changes, are important in runtime environment environments for AIX 5.2 and AIX 5.3. In my experience with porting - I have been able to trace all these changes back to new features in a gcc compiler. New features need new libraries. And, so the next question....

I see a version for AIX 4.3.3, AIX 5.1 and AIX 5.2, but not for AIX 5.3. When will the version for AIX 5.3 be available?

Right now. Use the version closest to the version you are using. If that is AIX 5.3, then the closest version is AIX 5.2. If you see a package without any version number it probably runs on all of them. But again, no guarantees. Maybe the developer decided that AIX 4.3.3 no lonber "exists", and made a single package for AIX 5.X. Try it. If it doesnt work, try to locate the project site and/or make a post on the forums under Applications. If I have time I will take a look at it. I have systems running AIX 4.3.3, 5.1, 5.2 and 5.3.
 
< Prev   Next >