This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]