This is the mail archive of the
mailing list for the libstdc++ project.
Re: [Lsb-wg] opposition to LSB 2.0 rc1
- From: anderson at freestandards dot org
- To: Joe Buck <Joe dot Buck at synopsys dot COM>
- Cc: gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, lsb-wg at freestandards dot org
- Date: Mon, 2 Aug 2004 19:36:05 -0400 (EDT)
- Subject: Re: [Lsb-wg] opposition to LSB 2.0 rc1
- References: <firstname.lastname@example.org><Pine.LNX.email@example.com><20040729223009.8074037D8D@carmen.fc.hp.com> <20040802161714.A25549@synopsys.com>
- Reply-to: anderson at freestandards dot org
On Mon, 2 Aug 2004, Joe Buck wrote:
> I do not
> want to favor any side, other than to suggest that if a major vendor finds
> it very difficult to support, the LSB will fail to be a useful standard
> that anyone can count on.
I've tried to treat all distributions equally, thus avoiding the
non-objective evaluation of 'major vendor'.
I admit that because we have a situation where not all distros are in
sync wrt upstream versions someone will have to be inconvenienced from
time to time. Hopefully, this inconvenience will not fall upon the same
vendor each release and will be evenly distributed over time.
In spite of this inconvenience, we believe that supporting the LSB
runtime is not overly difficult even if the distro is based on a gcc
version other than the one that best matches a release of the LSB.
> If it's considered urgent to pick some C++ LSB standard now, maybe it
> would be possible to declare it a stopgap, and plan another round that
> will standardize on a post-3.4 version (LSB 3.0?).
This is what we have been saying all along, though we haven't used the
term 'stopgap'. LSB 2.0 is based on what's in the field today, and has a
bounded lifespan. LSB 3.0 will be based on a later version, and likewise
will probably have a bounded lifespan.
> In either case, effort
> should then focus on ways to avoid repeating past mistakes: better ABI
> conformance testing mechanisms are badly needed. We've made improvements,
> but more can be done.
Yes, energy needs to be focused on improving things going forward. We
have created a test tool for measuring more of an ABI that we hope will
be useful for catching inadvertant changes in the future.
firstname.lastname@example.org Free Standards Group
Lead Developer, Written Specification Linux Standard Base
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149