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

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

On Tue, Sep 25, 2001 at 01:40:17PM -0400, Jakub Jelinek wrote:
> On Tue, Sep 25, 2001 at 10:36:47AM -0700, H . J . Lu wrote:
> > On Tue, Sep 25, 2001 at 12:22:10AM +0200, Jakub Jelinek wrote:
> > > 
> > > > Aport from the problem indicated above, there's no point in installing
> > > > Jakub's patch as long as libstdc++ still contains a copy of
> > > > __frame_state_for.  A remedy was briefly discussed on libc-alpha,
> > > 
> > > I believe it is a task for distribution vendors to fix up their
> > > compatibility compilers (note all of them need to be fixed, not just
> > > 2.95.latest).
> > > 
> > > > see:
> > > > 
> > > >   http://sources.redhat.com/ml/libc-alpha/2001-09/msg00017.html
> > > > 
> > > > and subsequent messages.  I'm not sure concensus has been reached on
> > > > this issue.
> > > 
> > > I think rth's suggested -( -lc -lgcc -) may be costly (as libc symbol count
> > > is not exactly small), will need to check what ld will actually do in that
> > > case.
> > 
> > Can't we make __frame_state_for in libgcc.a from gcc 2 STV_HIDDEN? Of
> > course, we should only do it for Linux. It shouldn't be too hard to do.
> > I can provide a patch if needed.
> 
> You need the exact opposite: __frame_state_for should be in libc.so only and
> not in any other shared library or binary, eventhough it is in libgcc.a.
> Similarly for frame registry/deregistry.

Ok. Let's #ifdef out __frame_state_for and registry/deregistry stuff
from libgcc.a in gcc 2 if it is configured for glibc which supports gcc
3. It should be straight forward.


H.J.