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

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

On Mon, Sep 24, 2001 at 11:34:04PM +0200, Mark Kettenis wrote:
> "H . J . Lu" <hjl@lucon.org> writes:
> 
> > Ok, I will buy that. But it was not clear to me what dlopening
> > libgcc_s.so.1 could do and wouldn't do. Assuming what you said is true,
> > I have some questions on its effectiveness. When it happens, your
> > scheme will only work when libgcc_s.so.1 is also upgraded to the
> > compatible one which is used to compile the C++ applications. I'd like
> > to ask
> > 
> > 1. How often is it true?
> > 2. If libgcc_s.so.1 is upgraded and we don't do dlopening libgcc_s.so.1
> > in glibc, how often won't the functions in libgcc_s.so.1 be used?
> > 
> > I have an impression that for most cases, the functions in libgcc_s.so.1
> > will be used anyway regardless if you do dlopening libgcc_s.so.1 or not.
> > 
> 
> Dlopening libgcc_s.so.1 only happens in a response to a call to
> __frame_state_for(), that is, for C++ code generated by GCC 2.  In
> general libgcc_s.so.1 will not be already loaded in that case.
> 

I don't think it is very useful unless I missed something very obvious.
May I ask under what condition the C++ code generated by gcc 2 will
call __frame_state_for in gcc 3? It seems to me that it will only
happen in libc.so compiled by gcc 3. Why can't we put a check in glibc
such that only the compatible versions of gcc 3 can be used to compile
glibc? That is __frame_state_for in glibc should be compatible with the
gcc 3 used to build it. Is that too much to ask?


H.J.