Re: supporting multiple versions of GCC with a single shared object release?

[mario guerra <emailformario@yahoo.com>]

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 <brian.budge@gmail.com> wrote:

> From: Brian Budge <brian.budge@gmail.com>
> 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 <emailformario@yahoo.com>
> 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 <emailformario@gmail.com>
> 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
> >>
> >
> >
>