This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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  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 ?
> -mike

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!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]