After three years of hibernation, LSB has finally produced a deliverable. It is called the Linux Development Platform Specification or LDPS Version 1.0. According to the LDPS 1.0 document, “This specification is designed so that programs developed on a conforming platform are expected to be portable to all generally available Linux distributions as of Oct. 7, 2000.”
Does it meet this goal? Not at all. Let me illustrate through one example: ncurses. The ncurses library provides programmers with a common way to write sophisticated character-mode applications.
In order to be LDPS 1.0 compliant, a distribution must include either ncurses version 4.2 or ncurses version 5.0.
The specification states that applications compiled for one version should run without modifications on the other with some exceptions. Then the specification goes on to list some of those exceptions.
By admitting the exceptions, LDPS 1.0 makes it clear that you can’t compile your application for one library version and expect it to run properly without first making sure you haven’t used some feature that would cause incompatibilities.
Since the LDPS 1.0 document does not attempt to detail all of the possible incompatibilities, you’re basically on your own.
One doesn’t need to go any further to conclude that LDPS 1.0 is meaningless with regard to ncurses. Yet it gets worse.
The LDPS document indicates that the following distributions, among others, are LDPS 1.0 compliant: Caldera 2.4, Debian 2.2, Mandrake 7.0 and Red Hat 6.2.
Caldera 2.4 includes ncurses 4.2 and puts the library in the directory /lib. Debian 2.2 seems to have both ncurses 4.2 and ncurses 5.0, and also puts the libraries in the /lib directory.
I don’t have a copy of Mandrake 7.0 to check, but Mandrake 7.1 includes several versions of ncurses, including both 4.2 and 5.0. All the libraries go in /usr/lib. Red Hat 6.2 includes a package that is labelled as ncurses 5.0, but if you examine the contents of the package, you will only find libraries for ncurses 4.0.
As far as I can tell, Red Hat does not even create symbolic links to give the impression that ncurses 5.0 libraries are installed. I assume this is a packaging error that may be fixed by an update to 6.2. The 4.0 libraries are installed in the directory /usr/lib.
If your application expects to find the library named libncurses.so.4.2, then it will only run on Caldera and Debian. If it expects to find libncurses.so.4, it will only run on Debian or Mandrake. If it expects to find libncurses.so.4.0, then it will run on Red Hat or Mandrake. If it expects to find libncurses.so.5 then it will only run on Debian or Mandrake.
It is not difficult to modify the above distributions to accommodate all the variations on ncurses 4.2 and 5.0, but this is how you can expect the distributions to behave “out of the box.”
LDPS does nothing to encourage distributions to take the simple steps necessary to fix the problem. LSB is simply kow-towing to existing distributions with this specification when it should be pushing distributions to become more compatible. As I have said before, LSB needs more guts than that.
As for ncurses, here is one way the problem of incompatibility could be solved effectively. Require all distributions to produce updates that install both ncurses 4.2 and 5.0, and create the symbolic links necessary to provide every possible library name an application may expect to find.
Then LSB should award the recognition of compliance only to those distributions willing to produce the updates. Then and only then can you use LDPS as a reliable guideline for compatibility.
Granted, developers should be able to expect people to apply updates for their applications in order for them to work. But this is no different than when an application requires service pack 4 or later in order to run on Windows NT 4.0.
Surely if Linux expects to compete with Windows NT, it can work within the same framework as Windows NT.
Petreley is the founding editor of LinuxWorld (www.linuxworld.com). Reach him at nicholas@petreley.com.