This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [www-patch] bugs.html rewrite, part 6: section about upgrading the compiler


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

R.


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