opposition to LSB 2.0 rc1

[Benjamin Kosnik <bkoz at redhat dot com>]

The LSB 2.0 spec is likely to be announced at LW next week. This is
the first update of LSB in two years, and for the first time includes
a specification for the following libraries: C++, X11, Xext, Xt, GL,
ncurses, and some others.

The draft spec is here:
http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core.html
http://www.linuxbase.org/spec/booksets/LSB-Core-IA32/LSB-Core-IA32.html

It is believed that all parts of this spec, with the exception of C++, to be
noncontroversial and adoptable by most current and pending linux
distributions.

The C++ specification is problematic, for several reasons.

1) LSB C++ ABI specification is inadequate and ill-formed. 

   Attempting to qualify the C++ binary interface on linux solely by
   details of the C++ runtime library, without also detailing
   requirements of the underlying compiler, is insufficient. As a
   result the standard may have a fundamental and fatal flaw. Namely,
   that two incompatible C++ implementations, which have the same C++
   runtime library characteristics, are deemed compatible.

2) LSB C++ specification enshrines non-current, inferior technology.
   
   The draft LSB spec implies C++ support implemented by a future
   release of the gcc 3.3 compiler. As of today, the last gcc
   release in this series (gcc-3.3.4) cannot meet the LSB
   specification, although future releases (gcc-3.3.5) may.

   However, the current FSF release of gcc is gcc-3.4.1, which is
   incompatible with the older release series. This release provides
   substantial benefits to users, including increased compiler and
   runtime performance, increased conformance to C99 and C++
   standards, and innovative new features.

   This page has the full details:
   http://gcc.gnu.org/gcc-3.4/changes.html

   In addition, the gcc developers have been working with other
   members of the C++ community, and as such gcc-3.4.x provides
   increased compiler and runtime compatibility with other vendor
   solutions.

3) LSB C++ specification is not multi-vendor.

   The draft LSB spec privileges linux distributions that are based
   on gcc-3.3. For distributions using gcc-3.2, conforming to LSB will
   require the addition of a duplicate yet incompatible system
   library, with the same name, same SONAME, and different path. This
   is problematic from an architectural standpoint, and may introduce
   unsupportable configurations. This may be considered a port of
   Microsoft's "DLL hell" to linux.

   In response, this LSB has advocated the use of dynamic loader
   tricks to solve this issue. A separate dynamic linker with special,
   LSB-only properties would purportedly solve the problem. Especially
   concerning are non-trivial, real-world cases, where applications
   need more runtime support than the subset of libraries standardized
   in the LSB specification. These libraries will drag in their own
   dependencies on the C++ ABI.  The LSB working group has repeatedly
   been pointed to this problem; the problem has been ignored since
   there are no dependencies of any other standardized library on
   libstdc++.  Conforming with the LSB specification just for the sake
   of passing the LSB test suite while ignoring the compatibility
   issues lingering in the shadows is not advisable.

These objections have been explained to the LSB, and their response
has not been satisfactory, although this effort is ongoing. Proposals
to drop the C++ parts of the LSB 2.0 specification were specifically
voted down.

Signed,
Benjamin Kosnik
Ulrich Drepper