> I'm sorta curious why linking against one of our small malloc > implementations still pulls in jemalloc:
Using my shell on ftp.n.o (9.0_STABLE): cc -v says the ld line for cc -o null null.c -lgnumalloc is ld -plugin /usr/libexec/liblto_plugin.so -plugin-opt=/usr/libexec/lto-wrapper -plugin-opt=-fresolution=/tmp//ccCNGMXD.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -dc -dp -e _start -static -o null /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbeginT.o /tmp//ccU1uPbn.o -lgnumalloc -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o Expecting that LTO would be unnecessary here, I scrapped all that and manually ran it with -Map= to generate a link map, which among other things describes why each archive member is brought in: % ld -Map=null.map -dc -dp -e _start -static -o null /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbeginT.o null.o -lgnumalloc -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o Looking at the resulting null.map, I see, among many other lines, /usr/lib/libc.a(jemalloc.o) /usr/lib/libc.a(tls.o) (calloc) which makes sense: if nothing in null.o, crt0.o, crti.o, or crtbeginT.o refers to anything in the libgnumalloc file containing calloc, nothing will have brought it in from libgnumalloc. Then, when libc refers to it internally, -lgnumalloc is past and thus unavailable for resolving it, so it comes from the default malloc in libc. So I tried, instead, % ld -Map=null.map -dc -dp -e _start -static -o null /usr/lib/crt0.o /usr/lib/crti.o /usr/lib/crtbeginT.o null.o --whole-archive -lgnumalloc --no-whole-archive -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o to force all of libgnumalloc to be brought in. Sure enough, this time, "je" does not appear in the link map, and the executable is significantly smaller. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
