This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Lsb-wg] opposition to LSB 2.0 rc1
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Matt Taggart <taggart at carmen dot fc dot hp dot com>
- Cc: anderson at freestandards dot org, Benjamin Kosnik <bkoz at redhat dot com>,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 16:17:14 -0700
- Subject: Re: [Lsb-wg] opposition to LSB 2.0 rc1
- References: <20040729111335.57e712fd.bkoz@redhat.com> <Pine.LNX.4.58.0407291552020.21442@trantor.stuart.netsweng.com> <20040729223009.8074037D8D@carmen.fc.hp.com>
On Thu, Jul 29, 2004 at 04:30:08PM -0600, Matt Taggart wrote:
> We're tracking the status of both the v5 and v6 ABIs wrt these criteria at,
>
> http://www.linuxbase.org/futures/candidates/c++/
> http://www.linuxbase.org/futures/candidates/c++v6/
Because of errors that the GCC team made, which are regrettable, it makes
no sense to say that there is a "v5 ABI". gcc 3.2.x and 3.3.x are not
compatible, but the version number was not bumped. I've received
complaints by private mail about the "elephant in the room" (that company
interests are at stake); I don't want to go there other than to say that
there are distros shipping 3.3.x gcc versions and other distros shipping
3.2.x gcc versions, meaning that any possible version of the LSB that
specifies either will be to the disadvantage of some company. 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. If any major distro objects to a proposed
standard, and it's not possible to deal with the objections, the main goal
(application portability) will not be achieved.
As a participant in the GCC team, I'd like to be able to put the 3.3
branch into deep-freeze soon, after one more release. Attempts to keep it
going indefinitely are likely to backfire, as backporting fixes is already
difficult and getting harder: the 3.4 C++ parser is completely different,
and the 3.5 "middle end" is completely different (tree-ssa).
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?). Another possibility
would be to delay the C++ portion of the standard. 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.