Re: Problem with removing atexit.

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

On Tue, May 01, 2001 at 09:42:05AM -0700, H . J . Lu wrote:
> On Tue, May 01, 2001 at 12:28:15PM -0400, Ben Collins wrote:
> > On Tue, May 01, 2001 at 09:20:56AM -0700, H . J . Lu wrote:
> > > On Tue, May 01, 2001 at 11:52:45AM -0400, Ben Collins wrote:
> > > > > 
> > > > > Now, the question is, do we provide backward binary compatibility to
> > > > > DSOs built against glibc 2.0.x? Any comments?
> > > > 
> > > > This seems to be the same problem I ran into on non-i386, with a gcc
> > > > that didn't have the weaksym patch. It's not a compatibility problem,
> > > > it's a bug in gcc. The DSO's need to be recompiled with a recent gcc
> > > > (2.95.4 from CVS, or gcc-3.x)
> > > 
> > > If you have to recompile a DSO to work with glibc 2.2.3, it IS a
> > > compatibility issue. My question is, should we require people to
> > > recompile DSOs with a right gcc if they want to use glibc 2.2.3?
> > > I don't think we should. But I don't have a good solution at hand
> > > for this problem.
> > 
> > You have to recompile it only because it was compiled with a buggy gcc.
> > This isn't a compatibility issue any more than it is to not link with
> > -lc and thus not include libc_nonshared.a into libraries.
> > 
> 
> Wrong. Read my emails and think about it again. The problem is the
> current symbol version scheme doesn't provide the backward run-time
> binary compatibility for DSOs compiled without symbol version when
> we remove a default symbol.

I guess one way to help it is to have a libc-compat.so which contains
those default symbols which are removed. We can tell people to add
-lc-compat and LD_PRELOAD=libc-compat.so when needed. But I don't know
it is even worth to try or not.


H.J.