This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>> 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 libraries have been in previous version of
>the LSB.

Oops, sorry for the mistake. I was just going by the differences between
LSB-Core 2.0rc1's "Relevant Libraries" and LSB-1.3 Chapter 13 Libraries.

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

It may not be documented. However, I would expect this behavior to be
precisely defined in an ABI spec that was aiming at portability and
compatibility. This is what I mean when I say I think the LSB is
inadequate.

The specific scenario I'm thinking about is the following. Vendor A uses
the gcc-3.3.5 release, constructs libstdc++.so.5.0.7. Vendor B uses
gcc-3.2.3, with a backport of gcc-3.3.5's libstdc++.so.5.0.7. Both
compilers validate, both compilers can pass the LSB parts for libstdc++.

However, an application using only the LSB-approved and certified
libstdc++, that invokes any of the known differences between the two
underlying compilers (see gcc bugzilla, ABI) will behave differently at
runtime on systems from Vendor A and Vendor B. This is surprising to me!

I think we can and should do better.

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

Um, great. Given the past trajectory of the LSB and LSB standards,
please excuse me if I remain skeptical of these proposed time lines.

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

Regardless, I believe this is best avoided if at all possible.

It still seems odd to me that this "pathspace" idea is not qualified in the standard.

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

Some of the ABI issues were only made public recently, as non-FSF
compiler vendors, working with GCC contributors, worked to ensure
increased ABI compatibility between gcc-3.4 and these proprietary
compilers. 

Given these developments, I think the FSG might want to re-think some of
their previous assumptions. If this means delaying the C++ bits of LSB
2.0, then I think that is a step that should be honestly considered.
It's far better to have no specification than a flawed one.

best,
benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]