GCC-3.0.1 can't compile Glibc-2.2.4
H . J . Lu
hjl@lucon.org
Tue Oct 2 10:24:00 GMT 2001
On Tue, Oct 02, 2001 at 07:20:08PM +0200, Jakub Jelinek wrote:
> 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++).
I was talking about the implementation of __frame_state_for which is
used by the old C++ binaries.
>
> > 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.
Again, I was talking about __frame_state_for.
>
> > 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).
I was talking about __frame_state_for. Do we ban installing the libc.so
binary compiled with gcc 3 on a system where gcc 3.0 is not installed?
H.J.
More information about the Libc-alpha
mailing list