Problem with removing atexit.

Problem with removing atexit.

[H . J . Lu]

On Mon, Apr 30, 2001 at 11:58:11PM -0700, Adam J. Richter wrote:
> baldur[501] cd /usr/lib
> baldur[502] objdump --dynamic-sym  libgpm.so libcurses.so | grep atexit
> 00000000      D  *UND*  00000000              atexit
				    ^^^^^^^^^^^^

Here is your problem. You have an unversioned reference to atexit.
Since the default atexit has been removed from libc.so and only
the atexit with version GLIBC_2.0 remains, any references to the
unversioned atexit will get a run-time error or have to be resolved
at the link time. You have to find out why you have unversioned
reference to atexit in DSO. It should only happen if you

1. Build the DSO against glibc 2.0.x. Or
2. Build the DSO without -lc. All the newer gcc should pass -lc to
ld when you do "gcc -shared" unless you tell gcc not to do so.

You have to find out what happened to your DSOs.

Now, the question is, do we provide backward binary compatibility to
DSOs built against glibc 2.0.x? Any comments?


H.J.

Re: Problem with removing atexit.

[Ben Collins]

On Tue, May 01, 2001 at 08:16:24AM -0700, H . J . Lu wrote:
> On Mon, Apr 30, 2001 at 11:58:11PM -0700, Adam J. Richter wrote:
> > baldur[501] cd /usr/lib
> > baldur[502] objdump --dynamic-sym  libgpm.so libcurses.so | grep atexit
> > 00000000      D  *UND*  00000000              atexit
> 				    ^^^^^^^^^^^^
> 
> Here is your problem. You have an unversioned reference to atexit.
> Since the default atexit has been removed from libc.so and only
> the atexit with version GLIBC_2.0 remains, any references to the
> unversioned atexit will get a run-time error or have to be resolved
> at the link time. You have to find out why you have unversioned
> reference to atexit in DSO. It should only happen if you
> 
> 1. Build the DSO against glibc 2.0.x. Or
> 2. Build the DSO without -lc. All the newer gcc should pass -lc to
> ld when you do "gcc -shared" unless you tell gcc not to do so.
> 
> You have to find out what happened to your DSOs.
> 
> 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)

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: Problem with removing atexit.

[H . J . Lu]

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.


H.J.

Re: Problem with removing atexit.

[Ben Collins]

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.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: Problem with removing atexit.

[H . J . Lu]

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.


H.J.

Re: Problem with removing atexit.

[H . J . Lu]

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.

Re: Problem with removing atexit.

[Ben Collins]

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 just tried running a bash that was compiled against glibc 2.0.7t
(along with a libncurses.so.3.4 and libreadline.so.2, also compiled
against 2.0.7t) and it worked fine.

$ objdump --dynamic-syms tmp/lib/libncurses.so.3.4 | grep atexit
00000000      DF *UND*  0000003e atexit
$ objdump --dynamic-syms /lib/libc-2.2.3.so | grep atexit
00019430 l    d  .rel__libc_atexit      00000000
0010c66c l    d  __libc_atexit  00000000
0002f110 g    DF .text  00000034 (GLIBC_2.0)  atexit
0002ef50 g    DF .text  00000048  GLIBC_2.1.3 __cxa_atexit
$ ldd tmp/bin/bash
        libreadline.so.2 => /home/bcollins/tmp/lib/libreadline.so.2 (0x40017000)
        libncurses.so.3.4 => /home/bcollins/tmp/lib/libncurses.so.3.4 (0x40042000)
        libdl.so.2 => /lib/libdl.so.2 (0x4008b000)
        libc.so.6 => /lib/libc.so.6 (0x4008f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ./tmp/bin/bash -c "echo hello"
hello
$ 

Are you absolutely sure this is a compatibility issue and not a toolchain
issue?

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: Problem with removing atexit.

[H . J . Lu]

On Tue, May 01, 2001 at 01:44:06PM -0400, Ben Collins wrote:
> 
> I just tried running a bash that was compiled against glibc 2.0.7t
> (along with a libncurses.so.3.4 and libreadline.so.2, also compiled
> against 2.0.7t) and it worked fine.
> 
> $ objdump --dynamic-syms tmp/lib/libncurses.so.3.4 | grep atexit
> 00000000      DF *UND*  0000003e atexit
> $ objdump --dynamic-syms /lib/libc-2.2.3.so | grep atexit
> 00019430 l    d  .rel__libc_atexit      00000000
> 0010c66c l    d  __libc_atexit  00000000
> 0002f110 g    DF .text  00000034 (GLIBC_2.0)  atexit
> 0002ef50 g    DF .text  00000048  GLIBC_2.1.3 __cxa_atexit
> $ ldd tmp/bin/bash
>         libreadline.so.2 => /home/bcollins/tmp/lib/libreadline.so.2 (0x40017000)
>         libncurses.so.3.4 => /home/bcollins/tmp/lib/libncurses.so.3.4 (0x40042000)
>         libdl.so.2 => /lib/libdl.so.2 (0x4008b000)
>         libc.so.6 => /lib/libc.so.6 (0x4008f000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> $ ./tmp/bin/bash -c "echo hello"
> hello
> $ 
> 

It seems we do handle this case right.

H.J.