From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin v. Loewis" To: landauer@apple.com Cc: gcc@gcc.gnu.org Subject: Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?) Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909202217.AAA16351@mira.isdn.cs.tu-berlin.de> References: X-SW-Source: 1999-09n/msg00857.html Message-ID: <19990930180200.KFuGvkvO3LQTvPax_Md6ZQvvohIcGpRjrv4Kx2-MDiI@z> > Is there a more detailed description of what the known > incompatibilities are, and/or what C++ features might > trigger them, and/or whether there is a subset of C++ that > one might reasonably expect to work compatibly, say from > egcs 1.1 to gcc 2.95? I started collecting such information, but I don't know whether my list is complete. If anybody has additions, please let me know: - STL was updated. In particular, the Allocator implementation was replaced, and renamed. As a result, all mangled names mentioning an allocator (i.e. more or less *all* instantiations of standard templates) are binary-incompatible with egcs 1.1. As STL continues to evolve in a binary-incompatible manner, such changes are likely in the future. A number of other STL classes changed as well. I stopped writing down the changes when I noticed the allocator thing; feel free to diff between 1.1 STL and 2.95 STL if you need more details. - __start_cp_handler was introduced as part of libgcc, and the EH machinery. The old (i.e. 1.1) functions remain present, and it is ok to mix them with __start_cp_handler. It only means that you cannot link 2.95 object files with the 1.1 libgcc.a Anything else should be compatible. As I said, I may be missing things. Since people will continue to ask this question: If anybody knows of any other incompatibility, *please* let me know. As for compatibility with even older versions (egcs 1.0, gcc 2.8): Forget it. I have no complete list, but the changes to make EH thread-safe should break a large number of binaries; I believe STL was updated between 1.0 and 1.1, as well. > And is there anything describing likely C++ ABI changes in > near-future releases (2.9x for x > 5; and/or 3.0)? Well, it is very easy to find out what *currently* comprises the ABI changes in gcc 2.96, under the -fnew-abi flag; see cp/decl2.c for a details: - The squangling mechanism will break link compatibility. - honor-std breaks that as well, at least for std library things (primarily iostreams and STL) - vtable-thunks are enabled on all platforms (under new ABI), with an important fix still missing (but coming up) - the new ABI itself currently does the empty bases optimization, but different people have different ideas what else it could or should do. If the above counts as "anything", I guess I'm done. It is difficult to tell what changes exactly will be in the next compiler, especially as I did not mention libstdc++ v3 so far. If we get that, about every program using the std library will binary-break. So it is a safe bet that one of the upcoming releases will be totally incompatible with anything you are compiling right now. Exactly *when* this will happen is open at this time; different people have different views :-) Hope this helps, Martin P.S. I didn't include any sales talk about how great the future will be, and how important it is to give the new features to the users, and that users should either accept that as a fact of life, or continue with the compiler they got. I hope you'll understand all this, anyway, and that I'm speaking for myself, not as a representative of somebody or something.