From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17353 invoked by alias); 15 Apr 2009 17:09:32 -0000 Received: (qmail 17229 invoked by uid 22791); 15 Apr 2009 17:09:30 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from web34803.mail.mud.yahoo.com (HELO web34803.mail.mud.yahoo.com) (209.191.68.167) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Wed, 15 Apr 2009 17:09:24 +0000 Received: (qmail 72326 invoked by uid 60001); 15 Apr 2009 17:09:22 -0000 Message-ID: <586960.71134.qm@web34803.mail.mud.yahoo.com> Received: from [67.52.129.61] by web34803.mail.mud.yahoo.com via HTTP; Wed, 15 Apr 2009 10:09:22 PDT Date: Wed, 15 Apr 2009 17:09:00 -0000 From: mario guerra Subject: Re: supporting multiple versions of GCC with a single shared object release? To: Brian Budge Cc: 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/msg00182.txt.bz2 Hmmm....is there a way to force GCC to resolve all outstanding std library references at link time and still ship the final build as a dynamic shared object? I know it kind of defeats the purpose of having standard libraries to begin with, but it would solve the problem if it were possible. --- On Wed, 4/15/09, Brian Budge wrote: > From: Brian Budge > Subject: Re: supporting multiple versions of GCC with a single shared object release? > To: emailformario@yahoo.com > Date: Wednesday, April 15, 2009, 8:58 AM > Hi Mario - > > Many distributions ship with older versions of libstdc++.so > in order > to maintain compatibility with older binaries. > However, you're > fundamentally right: if you want to *guarantee* that > there are no ABI > breakages, you'd still need to make sure that they have > access to an > ABI-compatible libstdc++ (and any other c++ libraries you > link > against). > > Brian > > On Tue, Apr 14, 2009 at 8:41 PM, Mario Guerra > wrote: > > Brian, > > > > We thought about this approach, but even with a C > interface, wouldn't the underlying C++ library calls be > resolved with the potentially mismatched standard library? I > would be much obliged if you would describe the approach > you're thinking of in more detail. > > > > Thanks, > > Mario > > > > ------Original Message------ > > From: Brian Budge > > To: mario guerra > > Cc: gcc-help@gcc.gnu.org > > Subject: Re: supporting multiple versions of GCC with > a single shared object release? > > Sent: Apr 14, 2009 5:09 PM > > > > The only way I know of to do this reliably is to have > a C interface. > > The ABI breakages are definitely a bummer. The other > option is to > > have a build for each used ABI. > > > > On Tue, Apr 14, 2009 at 3:02 PM, mario guerra > wrote: > >> Hello all, > >> > >> I work for a chip company that produces a C++ > simulator for one of our > >> processor cores, which we deliver as a shared > object file. We've used > >> GCC version 3.3.3 to build it, since that is the > standard version > >> deployed within our company. However, some of our > customers are > >> attempting to incorporate our model into third > party simulation > >> environments which use different versions of GCC, > and this sometimes > >> causes segmentation faults at run time from calls > into the stdc++ > >> library. We're trying to find a way to support > customers who may be > >> using different versions of GCC without having to > create a custom > >> simulator build for each customer. > >> > >> Surely this problem has come up for others before. > I'm looking for any > >> suggestions as to how this problem might be > solved, any ideas would be > >> much appreciated. > >> > >> Thanks, > >> Mario > >> > > > > >