Re: [Lsb-wg] opposition to LSB 2.0 rc1

[anderson at freestandards dot org]

On Thu, 29 Jul 2004, Benjamin Kosnik wrote:

>
> 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.

Only C++ is new. The other librarries have been in previous version of
the LSB.

> 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.


The LSB includes by reference the Itanium C++ ABI
(http://www.codesourcery.com/cxx-abi/abi.html), which covers the
compiler behavior. The LSB supplements that specification by adding the
libstdc++ definitions.

Is there additional compiler behavior that is not covered by these? If
so, where is it documented?


> 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.

Current CVS on the 3.3 branch matches the specification. Distributions
have a long history of grabbing patches from CVS and backporting them
to previous releases. The patch needed in this case is trival, and should
cause no difficulty to backport.

I believe this same situation has existed previously with glibc, and
backporting a small number of changes was viewed as acceptabvle then.


>    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.

We look forward to aligning the C++ definition in the LSB to gcc 3.4
in the next major release (LSB 3.0), curently scheduled for Summer 2005.

It would not be possible to release an LSB aligned with gcc 3.4 at this
time as it does not meet the rest of our release criteria, which can be
found on our website at http://www.linuxbase.org/futures/criteria/index.html.

> 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.

The LSB requires only 18 libraries, most of which probably do not need
to be duplicated in this situation. This situation is that same situation
that has occured in the past with glibc versions. This is one of the
reasons the LSB criteria require 2 or more distributions to be shipping
(or shipping imminently) with the require version levels to match the
specification.

Older releases have often required updating to match newer LSB releases.
We do take into consideration wether or not such updated can occur with
a reasonable amount of effort or not.


>    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.

This has been the suggested method for the past 5 years. It has even
been used in the past by other distributions, so we believe the approach
to be viable.

>    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 applications have 3 choices:

1) Don't be an LSB application

2) Statically link all libraries which are not included in the LSB

3) Carry around a private copy of the shared libraries, in which case
   they can be considered to be a aprt of the application.

Again, these have been the options for over 5 years. Note that for
applications provided by a distribution, option 1 should be fine.


>    the problem has been ignored since
>    there are no dependencies of any other standardized library on
>    libstdc++.

Not ignored, but the idea of making the full stack of shared libraries
provided by a distribution available on top of the LSB has not been seen
as being in scope or a requirement. We are working to expand the scope
of the LSB to include more of that stack of libraries, but it has never
been our itention that the stack be provided in this manner.

> These objections have been explained to the LSB, and their response
> has not been satisfactory, although this effort is ongoing.

Even if our responses have not been satisfactory, we are pleased to be
having an ongoing dialog.

> Proposals to drop the C++ parts of the LSB 2.0 specification were
> specifically voted down.

We have input from other places that require C++ to be included. It's a
tough choice, but we believe we have followed the rules of the LSB
workgroup, and that LSB 2.0 matches the plan which has been published
for nearly a year now.



                                Stuart

anderson@freestandards.org                             Free Standards Group
Lead Developer, Written Specification                  Linux Standard Base
1024D/37A79149:                                        0791 D3B8 9A4C 2CDC A31F
                                                       BD03 0A62 E534 37A7 9149