More Compatibility Issues Easily Managed With LSB

It's easy to understand why compatibility between different operating systems is a complicated procedure. The differences in architecture between something like Windows and Linux are huge, which makes porting applications between these two operating systems no trivial task.

But what about porting between different distributions of Linux? There, the differences are not as great. But they can be enough to trip up application developers as they build their projects--even different versions of the same distro can have enough differences to cause the failure to run an application. These are the kinds of little things that can trip up a project in a big hurry; and they're the kind of thing that the Linux Standard Base toolset are designed to find before they become a headache for developers.

A recent example of version compatibility was discovered by LDN member Darren Davis, Technical Product Manager of Novell's Open Platform Solutions team. Davis works extensively with independent software vendors (ISVs) in his day job, and recently came across a seemingly small compatbility issue for ISVs that was caused by a change in a version change of the gcc.

An ISV Davis was working with had built an application that ran on Red Hat Enterprise Linux (RHEL) 5 and wanted to run that app on SUSE Enterprise Linux Server (SLES) 10. When they did, however, the app would break, returning a "Floating Point Exception" error.

Turns out, this is a known problem between applications that will run on RHEL 4 and return the same error on RHEL 5. The culprit? The ELF hash section (SHT_HASH) of the GNU C Compiler (gcc) that runs in RHEL 4 and its older related distros returns the sysv format for symbol resolution. But, in 2006, Red Hat introduced a new patch that introduced an optional ELF hash section replacement, which was optimized for speed and data cache accesses. The reason for the change was sound: the team estimated in tests this change would improve dynamic linking by about 50%.

But, the upshot of this change is that applications compiled with the gcc in RHEL 5 and Fedora Core 6 and beyond link to something entirely different. In gcc, the SHT_HASH section is gone, replaced by SHT_GNU_HASH and has the gnu format.

According to Avinesh Kumar, who explains this very well in his blogM:

"On systems with new tool-chain set, gcc (especially v 4.1 onwards) passes --hash-style=gnu to the linker, by default and hence the code generated has just SHT_GNU_HASH section. And when this binary is run on older system, it would fail to run, as the dynamic linker on those machine won't find SHT_HASH section, it is looking for."

Davis says the fix for this is pretty simple. To make binaries that are compatible across distributions, developers need to use the linker flag --hash-style=sysv when building their application. For example;

gcc helloworld.c -Wl,--hash-style=sysv -o helloworld

What's nice for developers using the LSB toolset is that within the Software Development Kit, lsbcc sets the hash style to sysv automatically, which circumvents this hurdle quite meatly. And, according to its development team, Linux Application Checker 2.1 detects these kinds of compatibility issues and reports if a tested application is built with the gnu hash style and therefore cannot be run on distributions that only support the sysv hash style.

Even more reasons to use the LSB toolset for maximizing application portability.