With more than one version of libc circulating, users must make sure that their software uses the same libc as their Linux version. And software developers have to make sure their products can run with the various libc versions.
In the case of free software, which is available in source code form, this isn't too much of a headache. Simply compile the program on your own system, making sure to set the proper compile-time flags based on which library your system normally uses. Most software that has been ported to Linux -- and updated within the last year -- can be configured to compile against glibc. Certainly everything on the current Red Hat version 5.2 is glibc-based; most other distributions are either already that way, or are moving there in their next release.
But while most free software can be recompiled for your system, commercial software and other programs that are supplied only in binary form have a problem. While many of them still ship versions for libc5 (which will still safely run on almost all systems), some vendors are only shipping software compiled against glibc, and this is causing grief for some users.
Follow the Development Trail
For one thing, the GNU development model isn't as well developed as the Linux one. Linux and many similar free software projects have separate streams for "development" and "ready for public use" releases. Linux development releases always have an odd number after the first decimal (1.3, 2.1) and production releases use even numbers (1.2, 2.0).
In the GNU model, there's only one stream and no distinction is made between production and development versions. The glibc Web page only mentions which version is "current," and they don't even specify minor revision numbers.
And this is what is causing the problem. Many early developers found that glibc version 2.0.6, which was what they were given to work with, was buggy. Red Hat made some necessary bug-fixes, called the result 2.0.7, and used that in its releases. Other distributions were shipped with 2.0.6, which wouldn't run all programs that were developed using 2.0.7. At least one major developer, Star Division, bypassed Red Hat's changes and made their own version 2.0.7, which was slightly (but significantly) incompatible with 2.0.6 and Red Hat's 2.0.7.
Now that the GNU project has finally released version 2.1, which all Linux distributions will eventually use, most of these problems should be solved. But some large Linux ISVs are finding the transition painful. For instance, Oracle has built their current Oracle8i Linux database software for glibc 2.0.6, and the proper one that will work against glibc 2.1 won't be available for at least a few months. In addition, some companies exploited various internal functions that were available in the development 2.0.6 but were removed in 2.1; now their software won't work without extensive rewriting.
Star Division, Oracle, and other software packagers have learned a painful lesson about the risks of jumping the gun and using components that have not standardized or settled into production versions. Namely, that they must be wary of release-numbering schemes that make no distinction between development and production versions. Not all free software development patterns are as well thought out as that of the Linux kernel.
Protect Yourself
Your best defense is to know what version of the Linux library you have and make sure you only get software that matches. And beware of software that ships with its own libc; it's not likely to be compatible with 2.1. In other words, "caveat ftpor" -- let the downloader beware.
Are you having libc problems? Let us know in the ZDNet Linux Forum. Or write to Evan directly at evan@starnix.com.
