This is the mail archive of the
mailing list for the glibc project.
Re: atexit in a glibc function
On Jun 16, 2012, at 1:00 AM, Mike Frysinger wrote:
> On Saturday 16 June 2012 00:35:27 Amittai Aviram wrote:
>> I have been writing a custom variant of glibc Version 2.14 that differs
>> primarily in malloc/malloc.c .
>> My malloc.c definitely #includes <stdlib.h>. Why doesn't the linker
>> recognize "atexit"? Thanks!
> because in the x86-64 port, atexit isn't provided by the C library. it's in
> libc_nonshared.a which means the symbol ends up in the final application, not
> in the libc.so. so you may not use atexit() inside of the C library.
OK, thanks! I'll have to work around that then.
> malloc (and friends) are designed to be overridden at runtime. create a
> shared library that exports those symbols and simply LD_PRELOAD it and those
> funcs will be called whenever memory is needed. why do you need to rebuild
> glibc to do what you want ?
That sounds like a good idea. But--for other reasons--I want to build my applications with static linkage. Wouldn't the linker notice conflicting definitions of malloc and refuse to continue? Thanks!