This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [www-patch] bugs.html rewrite, part 6: section about upgrading the compiler
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Gerald Pfeifer <gp at suse dot de>
- Cc: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>, gcc-patches at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Wed, 19 Nov 2003 13:20:05 +0000
- Subject: Re: [www-patch] bugs.html rewrite, part 6: section about upgrading the compiler
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> On Wed, 19 Nov 2003, Volker Reichelt wrote:
> > Well, the sentence would get way too long for my taste (about 4 lines in
> > the HTML source). I'd rather suggest the following:
> >
> > + <h4>ABI changes</h4>
> > +
> > + <p>The application binary interface (ABI) defines how the elements of
> > + classes are laid out, how functions are called, how function names are
> > + mangled etc. It usually changes with each major release (i.e. when the
> > + first or second part of the version number changes). You <em>must</em>
> > + recompile all C++ libraries, or you risk linker errors or crashing
> > + programs. However, the ABI is not changed with bug-fix releases (i.e.
> > + when the third part of the version number changes). The code should be
> > + binary compatible among these versions.</p>
>
> I like that one; it's much better than what I suggested. ;-)
While this has been historically true, the whole point of having a defined
ABI is to avoid the need to do this at every turn of the wheel.
I'm not sure we should be expressing our short-commings in this way, even
if it is a reflection of what's happened in the past.
R.