Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

HJ writes:
> 1. The gcc people have to agree that a shared libgcc fiasco is waiting
> to happen on Linux.

It is clear that there is the potential for problems with libgcc on
systems that use gcc as the main compiler (I don't see why GNU/Linux is
unique here), if care is not taken.  It's not clear to me why systems
that use glibc should have a difficulty that, say, the BSD people will
not have.  With libstdc++ we have extra problems because glibc and
libstdc++ share data structures for standard I/O.  But with glibc and
libgcc, there is no sharing of this type going on; things are much more
orthogonal.

> 2. The gcc people have to ask for feedbacks/solutions from the glibc
> people.

OK, glibc people, consider yourselves asked.  However, I *also* would like
to hear from maintainers of the C library on BSD systems as to what
problems *they* forsee (since they would also have a shared libgcc to deal
with).  There is nothing special about glibc here, though the glibc people
do have lots of valuable experience with symbol versioning and the like.

> But given that none of the gcc people see a fiasco coming on Linux, I
> don't how it can be resolved in gcc 3.0. The way I see it is
> 
> 1. gcc 3.0 is released sometime this year.
> 2. All Linux vendors discourage gcc 3.0 on their distributions without
> modifications.
> 3. Someone comes up with a Linux patch for gcc 3.0.
> 4. A gcc 3.x for Linux is released.
> 
> It seems gcc 2.7.2.3 all over again :-(.

Such a situation would not be acceptable, especially since, based on the
record, the GNU/Linux patch may become the de-facto standard without
sufficient testing and will have ill effects, or even cause an effective
fork (if some vendors like it and some don't).

3.0 is still probably some months away; we have some time still to get
this right.