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 10:51:58AM -0700, Ulrich Drepper wrote:
> "H . J . Lu" <hjl@lucon.org> writes:
> 
> > 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.
> 
> Calling exactly one implementation all the time is a good thing.  Even
> if the code exists in multiple places.

I thought it was always true regardless of dlopening libgcc_s.so.1 or
not.

> 
> Also, we will sometime later add a change which will allow compiling
> glibc without compatibility with old C++ ABIs.  Then we need the
> dlopen code anyway.
> 
> > 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.
> 
> This is very easy.  libgcc_s uses symbol versioning.  The symbols used
> by symbol versioning are visible though dlsym.  So, before getting the
> function pointers the code should try to get the symbol "GCC_3.0" (or
> whatever the symbol version is which corresponds to code which is in
> glibc itself.  If the symbol exists, use the libgcc_s.  Otherwise use
> the internal functions.

1. Jakub's patch doesn't do that.
2. This scheme will only work with symbol versioning. Are you proposing
it as the solution to gcc? Personally, I am all for it. But what about
the other gcc targets which don't have symbol versioning? Even if we
don't care those targets, we may need to do something in gcc for glibc
to get it to work.

My point is it is an unresolved issue and we need to work with the
gcc people to address it. But so far, my emails sent to the gcc mailing
list almost went to a black hole :-).


H.J.