This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
opposition to LSB 2.0 rc1
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Cc: libstdc++ at gcc dot gnu dot org, lsb-wg at freestandards dot org
- Date: 2004年7月29日 11:13:35 -0500
- Subject: opposition to LSB 2.0 rc1
- Organization: Red Hat / Chicago
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