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

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Oct 02, 2001 at 09:56:10AM -0700, H . J . Lu wrote:
> 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?

That implementation is there for the case when glibc 2.2.5 was built with
gcc < 3. If you build some C++ libraries or C libs with -fexceptions using
gcc 3 and above, then you simply have to install libgcc_s.so.1 (otherwise no
C++).

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

As Richard explained to you already, if you wanted to do this kind of
runtime check, you'd have to query all shared libraries for their
requirements, not just libc.so. And this is something you really cannot do
with symbol versioning.

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

See above. If you have a gcc3 system and don't have libgcc_s.so.1, it is
similar to not install /bin/sh or libc and wonder why apps don't work.

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

The __frame_state_for patch allows them to work, provided admin meets the
requirements (have the latest libgcc_s.so.1 installed).

	Jakub