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

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

[mario guerra]

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 <aph@redhat.com> wrote:

> From: Andrew Haley <aph@redhat.com>
> Subject: Re: supporting multiple versions of GCC with a single shared object  release?
> To: "John Fine" <johnsfine@verizon.net>
> Cc: "mario guerra" <emailformario@gmail.com>, 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.
> 


      

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

[Ian Lance Taylor]

mario guerra <emailformario@yahoo.com> writes:

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

Exception is handling is identical and compatible since 3.2 or so.

Ian

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

[Andrew Haley]

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.

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

[Ian Lance Taylor]

mario guerra <emailformario@yahoo.com> writes:

> --- On Tue, 4/14/09, Ian Lance Taylor <iant@google.com> wrote:
>> The C++ compiler/library is supposed to have a stable ABI
>> as of gcc 4.0
>> and later.  For earlier versions, you pretty much do
>> have to do a build
>> for each version.
>
> If we built our simulator with 4.x, wouldn't that potentially break
> some of our third party vendors who are still using some variant of
> 3.x? The 4.x library isn't backwards compatible, is it?

No, the 4.x library is not reliably backward compatible.  Actually it
may be backward compatible to 3.4, but not before that.  For earlier
versions you will still have to do a build for each version.

Ian

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

[mario guerra]

--- On Tue, 4/14/09, Ian Lance Taylor <iant@google.com> wrote:

> From: Ian Lance Taylor <iant@google.com>
> Subject: Re: supporting multiple versions of GCC with a single shared object   release?
> To: "mario guerra" <emailformario@gmail.com>
> Cc: gcc-help@gcc.gnu.org
> Date: Tuesday, April 14, 2009, 5:21 PM
> mario guerra <emailformario@gmail.com>
> writes:
> 
> > 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.
> 
> The C++ compiler/library is supposed to have a stable ABI
> as of gcc 4.0
> and later.  For earlier versions, you pretty much do
> have to do a build
> for each version.
> 
> Ian
>

Hi Ian, 

If we built our simulator with 4.x, wouldn't that potentially break some of our third party vendors who are still using some variant of 3.x? The 4.x library isn't backwards compatible, is it?

Mario


      

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

[mario guerra]

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


      

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

[John Fine]

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.

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.

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

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.

mario guerra wrote:
> 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. 

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

[Ian Lance Taylor]

mario guerra <emailformario@gmail.com> writes:

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

The C++ compiler/library is supposed to have a stable ABI as of gcc 4.0
and later.  For earlier versions, you pretty much do have to do a build
for each version.

Ian

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

[Brian Budge]

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
>

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

[mario guerra]

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