libstdc++ compatibility

libstdc++ compatibility

[Matthias Klose]

As far as I undestand, the C++ compiler interface changed from
egcs-1.0.x to egcs-1.1. Is still possible to compile a libstdc++2.8
(not 2.9) with egcs-1.1 that is binary compatible with a libstdc++2.8
compiled with egcs-1.0.x ?

Thanks, Matthias

Re: libstdc++ compatibility

[Jeffrey A Law]

  In message < 13863.33627.732767.717335@gargleblaster >you write:
  > As far as I undestand, the C++ compiler interface changed from
  > egcs-1.0.x to egcs-1.1. Is still possible to compile a libstdc++2.8
  > (not 2.9) with egcs-1.1 that is binary compatible with a libstdc++2.8
  > compiled with egcs-1.0.x ?
Unlikely due to the changes necessary to support thread safe exception
handling.   There may be other issues, but that's the one that comes up
the most often.

jeff

Re: libstdc++ compatibility

[Joe Buck]

>   In message < 13863.33627.732767.717335@gargleblaster >you write:
>   > As far as I undestand, the C++ compiler interface changed from
>   > egcs-1.0.x to egcs-1.1. Is still possible to compile a libstdc++2.8
>   > (not 2.9) with egcs-1.1 that is binary compatible with a libstdc++2.8
>   > compiled with egcs-1.0.x ?
> Unlikely due to the changes necessary to support thread safe exception
> handling.   There may be other issues, but that's the one that comes up
> the most often.

Evidently this point is an issue for Red Hat: they don't want to ship
egcs-1.1 because it breaks binary compatibility with egcs-1.0.x, for
this reason.

I suppose Red Hat could patch 1.1 to generate thread-unsafe exceptions
in a way that gives compatibility with 1.0.x.

Re: libstdc++ compatibility

[Jeffrey A Law]

  In message < 199810172249.PAA00971@atrus.synopsys.com >you write:
  > 
  > >   In message < 13863.33627.732767.717335@gargleblaster >you write:
  > >   > As far as I undestand, the C++ compiler interface changed from
  > >   > egcs-1.0.x to egcs-1.1. Is still possible to compile a libstdc++2.8
  > >   > (not 2.9) with egcs-1.1 that is binary compatible with a libstdc++2.8
  > >   > compiled with egcs-1.0.x ?
  > > Unlikely due to the changes necessary to support thread safe exception
  > > handling.   There may be other issues, but that's the one that comes up
  > > the most often.
  > 
  > Evidently this point is an issue for Red Hat: they don't want to ship
  > egcs-1.1 because it breaks binary compatibility with egcs-1.0.x, for
  > this reason.
  > 
  > I suppose Red Hat could patch 1.1 to generate thread-unsafe exceptions
  > in a way that gives compatibility with 1.0.x.
That's a good question!

If there's not any other binary compatibility problems disabling thread
support at configure time may give Red Hat a way to upgrade from egcs-1.0.3.

jeff

Re: libstdc++ compatibility

[Joe Buck]

>   > Evidently this point is an issue for Red Hat: they don't want to ship
>   > egcs-1.1 because it breaks binary compatibility with egcs-1.0.x, for
>   > this reason.
>   > 
>   > I suppose Red Hat could patch 1.1 to generate thread-unsafe exceptions
>   > in a way that gives compatibility with 1.0.x.
> That's a good question!
> 
> If there's not any other binary compatibility problems disabling thread
> support at configure time may give Red Hat a way to upgrade from egcs-1.0.3.

Any Red Hat folks reading this?  It would be nice to have a version that
you don't have to patch (give you the right configuration options
instead).

Re: libstdc++ compatibility

[H.J. Lu]

>   > 
>   > Evidently this point is an issue for Red Hat: they don't want to ship
>   > egcs-1.1 because it breaks binary compatibility with egcs-1.0.x, for
>   > this reason.
>   > 
>   > I suppose Red Hat could patch 1.1 to generate thread-unsafe exceptions
>   > in a way that gives compatibility with 1.0.x.
> That's a good question!
> 
> If there's not any other binary compatibility problems disabling thread
> support at configure time may give Red Hat a way to upgrade from egcs-1.0.3.
> 

Did I miss something? I am running RedHat 5.1. I have no problems
using both egcs 1.0.3 and egcs 1.1. One thing helps me is the library
interface. If you want to change egcs 1.1.1 for RedHat, how about
my library interface? It can be specific for RedHat. I can provide the
patch. RedHat can some minor changes to make egcs 1.0.3 happy with the
patched egcs 1.1.1.


-- 
H.J. Lu (hjl@gnu.org)

Re: libstdc++ compatibility

[Cristian Gafton]

On Sat, 17 Oct 1998, Joe Buck wrote:

> >   > I suppose Red Hat could patch 1.1 to generate thread-unsafe exceptions
> >   > in a way that gives compatibility with 1.0.x.
> > That's a good question!
> > 
> > If there's not any other binary compatibility problems disabling thread
> > support at configure time may give Red Hat a way to upgrade from egcs-1.0.3.
> 
> Any Red Hat folks reading this?  It would be nice to have a version that
> you don't have to patch (give you the right configuration options
> instead).

I have been playing with egcs 1.1 for a while now, and disabling thread
support is not a option that I would like to proceed with. Most likely we
will ship a compatibility package that will include the current libcstdc++
2.8 generated by 1.0.3a so that apps linked against this libstdc++ will
continue to work. (much the saem way we did with libstdc++.2.7.2 in RH
5.1)

Cristian
--
----------------------------------------------------------------------
Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.

Re: libstdc++ compatibility

[Jeffrey A Law]

  In message < Pine.LNX.4.04.9810180933211.2007-100000@alien.devel.redhat.com >yo
u write:
  > > Any Red Hat folks reading this?  It would be nice to have a version that
  > > you don't have to patch (give you the right configuration options
  > > instead).
  > 
  > I have been playing with egcs 1.1 for a while now, and disabling thread
  > support is not a option that I would like to proceed with. Most likely we
  > will ship a compatibility package that will include the current libcstdc++
  > 2.8 generated by 1.0.3a so that apps linked against this libstdc++ will
  > continue to work. (much the saem way we did with libstdc++.2.7.2 in RH
  > 5.1)
I'm curious how you do this, do you keep an egcs-1.0.3 compiler around just
to build libstdc++-2.8?  Or do you build it with a hacked egcs-1.1?  Or do
you distribute a binary?

Just trying to wrap my head around the problem....

jeff

Re: libstdc++ compatibility

[Cristian Gafton]

On Sun, 18 Oct 1998, Jeffrey A Law wrote:

> I'm curious how you do this, do you keep an egcs-1.0.3 compiler around just
> to build libstdc++-2.8?  Or do you build it with a hacked egcs-1.1?  Or do
> you distribute a binary?

<shame on>
Distribute a binary from egcs 1.0.3 package.
</shame>

Cristian
--
----------------------------------------------------------------------
Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.

Re: libstdc++ compatibility

[Todd Vierling]

On Sat, 17 Oct 1998, Jeffrey A Law wrote:

: If there's not any other binary compatibility problems disabling thread
: support at configure time may give Red Hat a way to upgrade from egcs-1.0.3.

Um, what's wrong with `ship the appropriate runtime binary shlib
separately'?

If you're compiling C++ shared libraries, you should be expecting to lose
binary compatibility in the next generation of the library.  C++ is
_extremely_ difficult (and in some cases impossible) to keep binary
compatibility with.

We found this out the hard way with NetBSD 1.3 - a seemingly minor change
should have been a major shlib bump, and wasn't; hence NetBSD 1.2 C++
binaries broke on NetBSD 1.3.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)

Re: libstdc++ compatibility

[Jeffrey A Law]

  In message < Pine.LNX.4.04.9810181406440.2394-100000@alien.devel.redhat.com >
  > you write:
  > <shame on>
  > Distribute a binary from egcs 1.0.3 package.
  > </shame>
Ok.

So, in the future if you could build these old libstdc++ releases with a 
new compiler and get something that is compatible for code which linked
against the old libstdc++ you'd be OK?

We certainly can't do it yet, but it might be something we can pull off in
the future.

The question in my mind is how can we test this functionality?  Just being
able to build the old library isn't enough, we have to verify to some extent
that it is compatible with the old one.

We've also got to get a handle on when we actually make incompatible changes.
We've started thinking about that some, but not enough IMHO.

Thoughts anyone?

jeff 

Re: libstdc++ compatibility

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 > Did I miss something? I am running RedHat 5.1. I have no problems
 > using both egcs 1.0.3 and egcs 1.1. One thing helps me is the library
 > interface. If you want to change egcs 1.1.1 for RedHat, how about
 > my library interface?

The library interface patch is irrelevant, since the version number was
bumped for 1.1.

Jason

Re: libstdc++ compatibility

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 >> The library interface patch is irrelevant, since the version number was

 > If that is true, why cannot egcs 1.0.3 and 1.1.1 co-exist?

They can.  The reason RedHat didn't ship 1.1 was because they didn't want
another copy of libstdc++, not because they couldn't co-exist.

Jason

Re: libstdc++ compatibility

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 >> They can.  The reason RedHat didn't ship 1.1 was because they didn't want
 >> another copy of libstdc++, not because they couldn't co-exist.

 > What is wrong with a new libstdc++?

It can't be shared with processes using the old one.  I don't personally
consider this a strong argument, and it looks like RedHat has changed their
position, too.

 > Making libstdc++ in egcs 1.1 on RedHat thread-unsafe and not compatible
 > with other Linux configurations is a very big mistake. I hope RedHat
 > won't do that.

It doesn't look like they plan to.

Jason

Re: libstdc++ compatibility

[H.J. Lu]

> 
> >>>>> H J Lu <hjl@lucon.org> writes:
> 
>  > Did I miss something? I am running RedHat 5.1. I have no problems
>  > using both egcs 1.0.3 and egcs 1.1. One thing helps me is the library
>  > interface. If you want to change egcs 1.1.1 for RedHat, how about
>  > my library interface?
> 
> The library interface patch is irrelevant, since the version number was

If that is true, why cannot egcs 1.0.3 and 1.1.1 co-exist? If you take
a closer look at my library interface, you will see it supports N
different C++ compilers/libraries by

1. Put

libstdc++-$(LIBSTDCXX_INTERFACE)$(LIBC_INTERFACE)$(CXX_INTERFACE)-$(VERSION)

in $(prefix)/lib.

2. Put symlinks of libstdc++.so and libstdc++.a in the compiler
directory.

It is how my library interface works. We just need to retrofit the
egcs 1.0.3 binaries to get it to work. The key to solve the RedHat
problem is (2). Did I miss something?


-- 
H.J. Lu (hjl@gnu.org)

Re: libstdc++ compatibility

[H.J. Lu]

> 
> >>>>> H J Lu <hjl@lucon.org> writes:
> 
>  >> The library interface patch is irrelevant, since the version number was
> 
>  > If that is true, why cannot egcs 1.0.3 and 1.1.1 co-exist?
> 
> They can.  The reason RedHat didn't ship 1.1 was because they didn't want
> another copy of libstdc++, not because they couldn't co-exist.
> 

What is wrong with a new libstdc++? It is supposed to be thread-safe.
There are quite a few C++ packages which need a thread-safe libstdc++.
I was even asked to make a patch for egcs 1.0.3 to generate the
thread-safe libstdc++. I told them to wait for egcs 1.1. Making
libstdc++ in egcs 1.1 on RedHat thread-unsafe and not compatible with
other Linux configurations is a very big mistake. I hope RedHat won't
do that.


-- 
H.J. Lu (hjl@gnu.org)

Re: libstdc++ compatibility

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

 > So, in the future if you could build these old libstdc++ releases with a 
 > new compiler and get something that is compatible for code which linked
 > against the old libstdc++ you'd be OK?

 > We certainly can't do it yet, but it might be something we can pull off in
 > the future.

Why can't they just ship the old binary built with the old compiler?

 > The question in my mind is how can we test this functionality?  Just being
 > able to build the old library isn't enough, we have to verify to some extent
 > that it is compatible with the old one.

 > We've also got to get a handle on when we actually make incompatible
 > changes.  We've started thinking about that some, but not enough IMHO.

Yes.  We should have tests for binary compatibility in the testsuite, so we
catch inadvertent breakages.

Jason

Re: libstdc++ compatibility

[Cristian Gafton]

On Sun, 18 Oct 1998, Jeffrey A Law wrote:

> So, in the future if you could build these old libstdc++ releases with a 
> new compiler and get something that is compatible for code which linked
> against the old libstdc++ you'd be OK?

I think working on this thing (compiling old libstdc++ code with a new
compiler and keeping binary compatibility) is not worth the time, when it
is so easy to just package up a compatibility thing that will include
binaries compiled with the old compiler, binaries that we know to work,
etc.

> The question in my mind is how can we test this functionality?  Just being
> able to build the old library isn't enough, we have to verify to some extent
> that it is compatible with the old one.

IMHO it is not worth it.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton   --   gafton@redhat.com   --   Red Hat Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.

Binary Compatibility [was Re: libstdc++ compatibility]

[Brendan Kehoe]

> The question in my mind is how can we test this functionality?  Just being
> able to build the old library isn't enough, we have to verify to some extent
> that it is compatible with the old one.
> 
> We've also got to get a handle on when we actually make incompatible changes.
> We've started thinking about that some, but not enough IMHO.
> 
> Thoughts anyone?

On my ``Do This Soon'' list is the idea of putting together a suite of tests
that do testing of binary compatibility in g++.  It'd include things like
check object layout, different pieces of symbol mangling, exception handling
layout, RTTI, virtual function calling & tables, etc etc.  This seemed like a
great time to drop the question out for comment.

Does anyone have any ideas on how such a thing might be put together?  The
goal would be to make it easier to catch binary incompatibilities when they're
introduced, rather than waiting (unconsciously) until a user bumps into 'em.

This is particularly the case as -fnew-abi continues to grow & expand.

Thoughts?  Ideas?

B

-- 
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Solutions, Sunnyvale, CA                                +1 408 542 9600

Web page: http://www.zen.org/~brendan/

Re: Binary Compatibility [was Re: libstdc++ compatibility]

[Joe Buck]

> On my ``Do This Soon'' list is the idea of putting together a suite of tests
> that do testing of binary compatibility in g++.

How about running the g++ test suite (rather, the subset of the g++ test
suite that links against libstdc++) using headers from the new egcs
version, but linking against a shared library from a "golden" version
(e.g. the one with egcs-1.1?).

Re: Binary Compatibility [was Re: libstdc++ compatibility]

[Martin von Loewis]

> Thoughts?  Ideas?

One thing I personally like to see is a mangler testsuite. I'm not
sure how to implement this. Ideally, I'd like to write

namespace Foo{
  void bar(){  // MANGLED bar__3Foov
  }
}

It would produce assembler code (or an object file?) and then somehow
check whether the symbol is present. Alternatively, it would try to
call the function mangled that way, and see if it is the right one.

Regards,
Martin

Re: Binary Compatibility [was Re: libstdc++ compatibility]

[Mumit Khan]

On Fri, 23 Oct 1998, Martin von Loewis wrote:

> One thing I personally like to see is a mangler testsuite. I'm not
> sure how to implement this. Ideally, I'd like to write
> 
> namespace Foo{
>   void bar(){  // MANGLED bar__3Foov
>   }
> }
> 
> It would produce assembler code (or an object file?) and then somehow
> check whether the symbol is present. Alternatively, it would try to
> call the function mangled that way, and see if it is the right one.
> 

Perhaps the gcc.dg/dll-* tests will help? That's the technique I use
to test for various DLL symbol names stuff in win32 (I got sick
of breaking these every time I changed something ...).

Regards,
Mumit