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:52 AM, Mike Frysinger wrote:
> On Saturday 16 June 2012 01:05:25 Amittai Aviram wrote:
>> 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.
> there's __attribute__((destructor))
>>> 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!
> it's even easier with static archives. specify your library first and only
> your malloc objects will get used.
You are right--it works great. Follow-up question: what do you mean by their being "designed to be overridden at runtime"? How do they differ from other library functions so that they are specifically designed with this in mind? Thanks!
PhD Student in Computer Science
646 483 2639