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] |
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] |