Re: GCC-3.0.1 can't compile Glibc-2.2.4

["H . J . Lu" <hjl at lucon dot org>]

On Tue, Oct 02, 2001 at 09:38:51AM -0700, Ulrich Drepper wrote:
> Mark Kettenis <kettenis@wins.uva.nl> writes:
> 
> > That's something for Ulrich to decide.  I remember him saying that he
> > didn't want the glibc release schedule dictated by the GCC release
> > schedule, and that he preferred to use the unwinder in libgcc_s.so.1
> > if it's available.
> 
> Correct.  The DSO gets dlopen()ed only for some ill-fated old
> applications.  New ones won't have the problem.  There is no reason to

But I have 3 problems with it:

1. We still have an implementation in libc.so. Are we going to keep it
compatible with the gcc used to build libc.so?
2. We still don't know for sure if libgcc_s.so.1 available at the
run-time is compatible with the gcc used to build libc.so.
3. If libgcc_s.so.1 is not available at the run-time and we don't
keep the libc.so's implementation compatible with the gcc used to
build libc.so, the old applications won't run correctly.

If we don't really care about the old applications, we should just
remove __frame_state_for from glibc.

> introduce a source-code dependencies (even if it might improve
> performance for those apps a bit).  Just see it from this side: if
> people don't like it they are more inclined to recompile their apps
> and get it right.  The only thing to be made sure is that libgcc can
> actually be dlopened() (without RTLD_GLOBAL) and does not require some
> magic loading.  This is I think the case.

I don't believe it is worth the trouble.


H.J.