The Linux Standard Base
standardization effort aimed at making Linux friendly for application
vendors. By nailing down issues like which libraries should be available,
how packages are to be managed, where files should reside, etc., the LSB
seeks to create a standard environment which will be present on every
compliant distribution. Application vendors can then build their offerings
for that environment and, with luck, have them run everywhere.
A major release of the LSB (version 2.0) is in the final stages. The
most recent plan had been to release this version at LinuxWorld, but, for
reasons we are about to get into, that release may be delayed a bit.
Version 2.0 adds a number of things; included therein is a description of
the environment which should be available for C++ applications. A great
many commercial programs are written in C++, so, for many vendors, the LSB
is of little use until it covers that language. So the C++ description is
a high-priority part of the LSB 2.0 release.
The standardization of the C++ environment has run into some opposition,
however, as seen by this posting to
the gcc list and the subsequent discussion. Many people, including a
number of gcc developers, are unhappy with the choices that have been made
for the LSB 2.0, and are pushing for changes.
The core of the problem is that the LSB specifies that compliant systems
must offer a modified version of the "v5 ABI." This is the binary
interface used by gcc 3.3; current versions of gcc 3.3, however,
are not compliant with the specification. Patches exist toward a future
3.3.5 release which will bring it into compliance; this release will
probably happen, though no promises to the effect have been made.
The real problem, however, is that gcc 3.3 is already old technology, and
is considered to be a dead end. Current development efforts are going into
gcc 3.4 and even 3.5; gcc 3.4 can already be found on some systems
(such as your editor's
Fedora Rawhide box). gcc 3.4 is widely held to be a superior release;
it has much improved performance, better interoperability with other C++
compilers, and better standards support. It also has a different and
incompatible binary interface, of course. Since the C++ environment is
only now being nailed down by the LSB, it is asked, why not go with the
newer, v6 ABI, which will actually be relevant into the future?
The reasons appear to come down to the following:
- The LSB is explicitly mandated to focus on existing, deployed
technology. At this time, none of the mainstream distributions are
shipping with the v6 ABI. Standardizing on that ABI would violate the
LSB requirements, and so will not be done.
- The 2.0 release has already been delayed; making a major change to the
C++ ABI specification would add another, long delay.
- The LSB 2.0 specification is planned to be submitted to the ISO/PAS
process. ISO certification would help vendors trying to sell Linux
solutions into a number of governmental and corporate environments.
That submission must happen by October, however, or the application
process must be restarted from the beginning.
- The v5 ABI is what (most) distributors are shipping now; standardizing
on that ABI will make it easier for existing distributions to be
brought into compliance.
Opponents argue that the version of the v5 ABI documented in the LSB has
never been distributed either - though, in all fairness, the required
changes appear to be small. The stronger complaints seem to be that the
LSB has made its choices based on the short-term needs of commercial Linux
distributors, to the detriment of what the community wants. Of course,
determining what the community wants can be problematic, especially since
Richard Stallman has prohibited the gcc
steering committee from cooperating with the LSB process.
The truth of the matter is that the Linux Standard Base is in a bit of a
bind. There is pressure from vendors to create a C++ standard in the near
future, the LSB 2.0 process has already taken longer than expected,
and, from the LSB's point of view, the v6 ABI has not yet reached a level
of deployment or stability that would allow it to be used as the basis for
a specification. The gcc C++ ABI remains a moving target, so any attempt to
write a standard based on it is bound to encounter difficulties. The
only option available at this time, assuming that the C++ section is not to
be dropped altogether, is to go with the v5 ABI.
We talked briefly with Stuart Anderson, the lead developer for the LSB
written specification. His belief is that the LSB 2.0 release will go
forward essentially unchanged, though perhaps with an added statement
regarding the C++ ABI and the fact that it will change in the future. The
v6 ABI will then be incorporated into the LSB
3.0 release, which is currently planned for about one year from now. It is
possible, however, that the C++ section will be dropped from the version of
the specification submitted to the ISO.
Standards are a tricky subject in the free software world; they promote
interoperability, but also freeze development in a community that values
its ability to make changes and move forward. Occasionally a standard
catches a development project at the wrong time; that appears to have
happened with the C++ specification. As a result, some people are upset
now. In a year or two, however, when the gcc C++ ABI has settled down and
found its way into future LSB releases, few people will remember this
to post comments)