[patch] init_array/fini_array support

Joseph S. Myers joseph at codesourcery.com
Fri Jan 20 15:17:00 UTC 2006

On Fri, 20 Jan 2006, Peter S. Mazinger wrote:

> > No, the comment in glibc is "We run the executable's destructor now just 
> > like any other." and I don't think this is the case for uClibc's ld.so (if 
> > it were, we'd already have been running _fini twice).
> Could you shed a light why glibc's comment on __libc_csu_fini is:
> "This function should not be used anymore. ... your comment above ...
> We cannot remove the function, though."
> They can't remove it probably because they have to keep glibc compatible 
> (being noop in case of the shared lib), but that is not uClibc's problem.

It used to be the case (hence "anymore" and "now") that glibc ran the 
program destructors from __libc_csu_fini, then it switched to run them 
from the dynamic linker.  It then turned out that __libc_csu_fini was 
needed after all by glibc for the static linking case.

The status quo in uClibc is that the program destructors aren't run from 
ld.so.  I see no particular advantage of one approach over the other (save 
to note that because of the static linking case we can't avoid having the 
__libc_csu_fini function in general), so kept the status quo rather than 
eliminating use of _fini for the dynamic linking case.

The change in glibc came in as part of a large and complicated auditing 

revision 1.4
date: 2005/01/06 22:40:27;  author: drepper;  state: Exp;  lines: +6 -1
        * csu/elf-init.c (__libc_csu_fini): Don't do anything here.
        * sysdeps/generic/libc-start.c: Don't register program destructor here.

followed by

revision 1.5
date: 2005/02/14 21:21:36;  author: drepper;  state: Exp;  lines: +1 -1
(__libc_csu_fini): Enable if LIBC_NONSHARED isn't defined.

to fix static linking.

Joseph S. Myers
joseph at codesourcery.com

More information about the uClibc mailing list