From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12549 invoked by alias); 17 Apr 2009 14:55:25 -0000 Received: (qmail 12540 invoked by uid 22791); 17 Apr 2009 14:55:24 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from web34802.mail.mud.yahoo.com (HELO web34802.mail.mud.yahoo.com) (209.191.68.166) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 17 Apr 2009 14:55:19 +0000 Received: (qmail 59861 invoked by uid 60001); 17 Apr 2009 14:55:17 -0000 Message-ID: <43380.59367.qm@web34802.mail.mud.yahoo.com> Received: from [67.52.129.61] by web34802.mail.mud.yahoo.com via HTTP; Fri, 17 Apr 2009 07:55:16 PDT Date: Fri, 17 Apr 2009 14:55:00 -0000 From: mario guerra Subject: Re: supporting multiple versions of GCC with a single shared object release? To: gcc-help@gcc.gnu.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg00211.txt.bz2 Thank you all for the helpful responses. Based on the info provided, it sounds like if we built our product with GCC version 4.x we would have binary compatibility at least back to 3.4.x, please let me know if my understanding is not right. On a related note, if we tried this approach would we have to worry about any differences in the implementation of exception handling between different versions of GCC? Thanks again, Mario --- On Thu, 4/16/09, Andrew Haley wrote: > From: Andrew Haley > Subject: Re: supporting multiple versions of GCC with a single shared object release? > To: "John Fine" > Cc: "mario guerra" , gcc-help@gcc.gnu.org > Date: Thursday, April 16, 2009, 12:05 PM > John Fine wrote: > > I have accidentally mixed binaries compiled by > gcc3.2.3 with binaries > > compiled by gcc3.4.6 in both directions across the > main program / .so > > boundary. I did that in both x86 and AMD64 > architectures. In all cases > > I have had crashes, usually in std::string. > > Right: libstdc++ wasn't stable. > > > I have mixed gcc3.4.6 with each of gcc4.1.2 and > gcc4.3.2 in similar > > combinations (but only in AMD64) and seen no similar > problems. > > It is now. > > > So there seems to be a significant change in > std::string (or something > > it depends on) somewhere between gcc3.2.3 and > gcc3.4.6, but no similar > > change since. > > > > So I think you would need to switch to some newer > version in order to > > provide compatibility across a range of versions, and > then I guess you > > would lose compatibility back to 3.3.3 > > Right. > > > BTW, if any of the experts here have specific warnings > (what won't work) > > across the range 3.4.6 through 4.3.2, I'd appreciate > them. The fact > > that it has all worked for me so far doesn't prove it > is safe. > > Well, we had to change the ABI several times as we were > tracking the > development of the standard, and even after the > multi-vendor C++ ABI > was finalized, we still made a couple of mistakes that > required a fix > that broke binary compatibility. That was, if I > remember correctly, > gcc 3.2.x. It's been pretty stable ever since. > > It's pretty easy to see when the ABI has changed because we > bump the > major release number in the soname. > > Andrew. >