This is the mail archive of the
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: Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>
- Cc: Richard dot Earnshaw at arm dot com, gp at suse dot de, gcc-patches at gcc dot gnu dot org
- Date: Wed, 19 Nov 2003 14:03:41 +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 19 Nov, Richard Earnshaw wrote:
> >> 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.
> Well, theoretically you're right: There should be only one ABI.
> But bugs.html is a trouble-shooting page for real problems of
> (non-expert) users. And I think we should be fair and warn them
> of potential problems.
> The old version of bugs.html stated:
> | <p>GCC 3.0 had a new ABI, which affected class layout, function mangling and
> | calling conventions. We had intended it to be complete, but unfortunately
> | some issues came to light, too late to fix in the 3.0 series.
> | The ABI should not change in dot releases, so we addressed most issues
> | in GCC 3.1.</p>
> But the same holds for the transition to 3.2 (which was done only
> because of ABI flaws) and to 3.3 and possibly to 3.4. Just continuing
> this list doesn't make much sense to me. So I (with help of others, but
> I'll take the blame) chose this wording to reflect of what's happened in
> the past.
> What would be your suggestion (that fits into 3 or 4 sentences)?
This isn't the final form, but I would think something along the lines of
GCC 3.0 introduced a new ABI which affected all aspects of compiling C++
programs. The intent of the change was to make G++ code compatible with
the emerging Generic C++ ABI. Unfortunately, the ABI is complex and at
this time we are still finding and fixing bugs in our implementation. If
you change your compiler (for example, from GCC 3.2 to GCC 3.3) you must
recompile all your libraries, or you will risk getting linker errors or
programs that do not execute correctly. However, it should not be
necessary to recompile if you have changed to a bug-fix release of the
same version of the compiler (for example, from GCC 3.3.0 and 3.3.1);
bug-fix releases are careful to avoid ABI changes.