Building a static libc using 2.3.5 causes symbols from malloc.c (namely free, malloc, and realloc) to be exported as non-weak due to the use of strong_alias. This causes problems when trying to interpose these functions during a static link with definitions from another object. For example: mbland:~/test/static_interpose$ cat > foo.c #include <stddef.h> void * malloc (size_t unused) { return 0; } int main (void) { (void) malloc (0); return 0; } mbland:~/test/static_interpose$ gcc foo.c mbland:~/test/static_interpose$ gcc -static foo.c /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../../lib/libc.a(malloc.o): In function `malloc': : multiple definition of `malloc' /tmp/ccCJFGaW.o:foo.c:(.text+0x0): first defined here /usr/bin/ld: Warning: size of symbol `malloc' changed from 10 in /tmp/ccCJFGaW.o to 397 in /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../../lib/libc.a(malloc.o) collect2: ld returned 1 exit status This example works in both cases with glibc-2.3.2, as these symbols were defined as weak in the 2.3.2 libc.a. Though I'm currently using glibc-2.3.5, I've noticed that the strong_alias instances still persist in the current CVS. I've built a static glibc with all the strong_alias instances changed to weak_alias, and successfully built a statically-linked executable with these symbols interposed. --- glibc-2.3.5-orig/malloc/malloc.c 2006-06-13 13:49:00.000000000 -0700 +++ glibc-2.3.5/malloc/malloc.c 2006-06-13 15:35:20.000000000 -0700 @@ -5566,11 +5566,11 @@ weak_alias (__posix_memalign, posix_mema strong_alias (__libc_calloc, __calloc) weak_alias (__libc_calloc, calloc) strong_alias (__libc_free, __cfree) weak_alias (__libc_free, cfree) -strong_alias (__libc_free, __free) strong_alias (__libc_free, free) -strong_alias (__libc_malloc, __malloc) strong_alias (__libc_malloc, malloc) +strong_alias (__libc_free, __free) weak_alias (__libc_free, free) +strong_alias (__libc_malloc, __malloc) weak_alias (__libc_malloc, malloc) strong_alias (__libc_memalign, __memalign) weak_alias (__libc_memalign, memalign) -strong_alias (__libc_realloc, __realloc) strong_alias (__libc_realloc, realloc) +strong_alias (__libc_realloc, __realloc) weak_alias (__libc_realloc, realloc) strong_alias (__libc_valloc, __valloc) weak_alias (__libc_valloc, valloc) strong_alias (__libc_pvalloc, __pvalloc) weak_alias (__libc_pvalloc, pvalloc) strong_alias (__libc_mallinfo, __mallinfo)
No. You cannot replace just parts of the implementation.
But what about the use case of hooking malloc? That requires the requested behavior, and yet it is not replacing part of the implementation.
This behavior prevents the TotalView memory debugging feature from working with statically link codes: $ cat main.c int main() { } $ gcc -static -g -L/opt/toolworks/totalview.8.6.0/linux-x86-64/lib -ltvheap_cnl_static -lpthread main.c /usr/lib/../lib64/libc.a(malloc.o): In function `free': (.text+0x1c90): multiple definition of `free' /opt/toolworks/totalview.8.6.0/linux-x86-64/lib/libtvheap_cnl_static.a:(.text+0x60d5): first defined here /usr/lib/../lib64/libc.a(malloc.o): In function `malloc': (.text+0x3fe0): multiple definition of `malloc' /opt/toolworks/totalview.8.6.0/linux-x86-64/lib/libtvheap_cnl_static.a:(.text+0x60e3): first defined here /usr/lib/../lib64/libc.a(malloc.o): In function `realloc': (.text+0x4470): multiple definition of `realloc' /opt/toolworks/totalview.8.6.0/linux-x86-64/lib/libtvheap_cnl_static.a:(.text+0x610d): first defined here collect2: ld returned 1 exit status $
Any insight why is strong alias in malloc et. al. needed?