This is the mail archive of the libc-help@sourceware.org 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 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.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


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