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)

------- Additional Comment #1 From Ulrich Drepper 2006-06-17 16:56 -------

No.  You cannot replace just parts of the implementation.

------- Additional Comment #2 From dank@kegel.com 2006-06-17 19:35 -------

But what about the use case of hooking malloc?
That requires the requested behavior, and yet it is
not replacing part of the implementation.

------- Additional Comment #3 From Geir Johansen 2009-03-12 22:06 -------

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
$