Re: [PATCH] Next attempt on the gcc3 vs glibc2.2.4 patch

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

On Tue, Aug 07, 2001 at 09:08:35PM +0200, Jakub Jelinek wrote:
> On Tue, Aug 07, 2001 at 08:56:52AM -0700, H . J . Lu wrote:
> > On Mon, Aug 06, 2001 at 04:41:36PM +0200, Jakub Jelinek wrote:
> > > Unlike the previous one, it does not care which gcc was used to build GLIBC
> > > - everywhere but on Linux/IA-64 it exports the new GCC 3.0 unwind
> > > register/deregister routines plus _Unwind_Find_FDE (using gcc's
> > > unwind-dw2-fde.c with just a few changes for glibc), plus on platforms which
> > > used to export __frame_state_for from glibc it does so. __frame_state_for
> > > implementation in GLIBC means first try to dlopen libgcc_s.so.1 if it exists
> > > and call __frame_state_for in there, if it does not exist, it has a
> > > fallback, so that GLIBC 2.2.4 does not require GCC 3.0.1+'s libgcc to be
> > > installed.
> > 
> > One more comment, I don't know what you will gain by dlopening
> > libgcc_s.so.1, given that those functions are also available in
> > libc.so. You can't say which ones are newer at the run-time, those
> > in libc.so or those in libgcc_s.so.1. I believe we should do a
> > run-time/link-time version check of those functions instead.
> 
> The run-time/link-time version check is IMHO not needed, once libgcc_s will
> need a different _Unwind_Find_FDE it can use different symbol version or
> even different name (but as Richard said, it is unlikely to happen soon).
> 

I have no doubt that symbol versioning will work. Has anyone tried
about how it will work without symbol versioning? On the other hand,
why do I care? I am happy as long as glibc works :-). The only thing
I want to hear is gcc will use symbol versioning on glibc when a
diffetent _Unwind_Find_FDE is needed.


H.J.