This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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


Benjamin Kosnik writes...

> 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 this is a general flaw in behavioural standards and is not specific 
to c++. The same case exists today with the existing libraries in the LSB.

The predecessor to LSB was the Linux Development Platform Specification
http://members.freestandards.org/ldps/

This approach specified specific implementations and specific versions of 
those implementations. It was dropped in favor of the LSB for several 
reasons.
1.) The runtime implementors felt it was too constraining and took away 
their flexibility to craft their distro the way they saw fit, and weren't 
willing to adopt it.
2.) It was thought to be impossible to get all the runtimes synced up on 
those versions at the same time and for long enough to make it an 
attractive platform for developers.
3.) By entrenching a particular implementation/version it took away a 
really nice feature of Free Software, the ability to fork. It was deemed 
that the benefit of the standard was not worth the price of giving up 
control to one particular implementation.

So we arrived at a behavioral model. The keys to making this model work,
1.) Attempt to document *all* interfaces that are presented to the 
developer, and if the developer shouldn't be using it don't specify it.
2.) Write assertion based tests for all interfaces.
3.) Count on finding problems and being able to fix them in the spec and 
test for them. Publish errata to the standard and iteratively improve it 
over time.

So it's not perfect, we need to work hard to make it work.

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

The LSB doesn't create standards, it only documents existing standards 
created by the community, so the LSB release schedule is dependent on the 
community's schedule. So it's not our fault :)

I'd like to note that c++ was first added as a candidate for consideration 
on 2002-04-08. It hasn't been added to an LSB release precisely because it 
wasn't ready upstream. I really don't think you want the LSB releasing 
things before it makes sense. And yes our skills predicting when a 
particular candidate will meet the criteria pretty much suck :)

[ld trick thing]
> Regardless, I believe this is best avoided if at all possible.

Yes, ideally.

> It still sems odd to me that this "pathspace" idea is not qualified in the s
> tandard.

Yes, it should be.

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

And I bet we can expect additional ABI issues to continue to come out in 
the future. Unless you think all the bugs have come out? (although I think 
people have thought that before with each of the 3.x releases, right?)

> 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 may come to that, I think we're just trying to prove to ourselves that 
waiting is the best answer.

> It's far better to have no specification than a flawed one.

This probably depends on the amount it's flawed. Will we ever have a 
perfect spec, and if so how long is it worth waiting for?  I'm mostly 
playing devil's advocate here, I want to prove whatever answer we arrive at 
is the best one.

Thanks,

-- 
Matt Taggart        Linux and Open Source Lab
taggart@fc.hp.com   Hewlett-Packard



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