利用LD_PRELOAD來載入tcmalloc庫那麼使用者呼叫malloc肯定是走到tcmalloc中；在編譯時顯式連結tcmalloc庫如何保證在執行時，malloc符號是繫結到tcmalloc內的？僅通過動態庫載入順序？還是有其它機制？試驗x86_64平臺。寫一個hello小程式，呼叫一次malloc函式。利用如下命令來檢視依賴庫及malloc符號的繫結結果：objdump -x a.out |grep NEEDEDLD_DEBUG=bindings ./a.out試驗1：不連結tcmalloc[[email protected] hello]$ objdump a.out -x |grep NEEDED NEEDED libc.so.6[

[email protected] hello]$ LD_DEBUG=bindings ./a.out 5363: initialize program: ./a.out 5363: 5363: 5363: transferring control: ./a.out 5363: 5363: binding file ./a.out [0] to /lib64/libc.so.6 [0]: normal symbol `malloc' [GLIBC_2.2.5] 5363: binding file ./a.out [0] to /lib64/libc.so.6 [0]: normal symbol `memset' [GLIBC_2.2.5] 5363: 5363: calling fini: ./a.out [0]試驗2：僅顯式連結tcmalloc

[[email protected] hello]$ gcc hello.c -ltcmalloc[[email protected] hello]$ objdump a.out -x |grep NEEDED NEEDED libtcmalloc.so.4 NEEDED libc.so.6[[email protected] hello]$ LD_DEBUG=bindings ./a.out 5414: initialize program: ./a.out 5414: 5414: 5414: transferring control: ./a.out 5414: 5414: binding file ./a.out [0] to /lib64/libtcmalloc.so.4 [0]: normal symbol `malloc' 5414: binding file ./a.out [0] to /lib64/libc.so.6 [0]: normal symbol `memset' [GLIBC_2.2.5] 5414: 5414: calling fini: ./a.out [0]試驗3：顯式連結libc和tcmalloc，libc在前

[[email protected] hello]$ gcc hello.c -lc -ltcmalloc[[email protected] hello]$ objdump a.out -x |grep NEEDED NEEDED libc.so.6 NEEDED libtcmalloc.so.4[[email protected] hello]$ LD_DEBUG=bindings ./a.out 5463: initialize program: ./a.out 5463: 5463: 5463: transferring control: ./a.out 5463: 5463: binding file ./a.out [0] to /lib64/libc.so.6 [0]: normal symbol `malloc' [GLIBC_2.2.5] 5463: binding file ./a.out [0] to /lib64/libc.so.6 [0]: normal symbol `memset' [GLIBC_2.2.5] 5463: 5463: calling fini: ./a.out [0]試驗4：顯式連結libc和tcmalloc，tcmalloc在前[[email protected] hello]$ gcc hello.c -ltcmalloc -lc[[email protected] hello]$ objdump a.out -x |grep NEEDED NEEDED libtcmalloc.so.4 NEEDED libc.so.6[[email protected] hello]$ LD_DEBUG=bindings ./a.out 5501: initialize program: ./a.out 5501: 5501: 5501: transferring control: ./a.out 5501: 5501: binding file ./a.out [0] to /lib64/libtcmalloc.so.4 [0]: normal symbol `malloc' 5501: binding file ./a.out [0] to /lib64/libc.so.6 [0]: normal symbol `memset' [GLIBC_2.2.5] 5501: 5501: calling fini: ./a.out [0]結論經過上述測試驗證（也作了libstdc++ / new函式的測試），當顯式連結libtcmalloc時，程序的malloc/new最終能不能調到tcmalloc中，取決於程序對動態庫的依賴順序。如果編譯軟體時，既顯式連結libc（或libstdc++），又顯式連結libtcmalloc，那麼必須保證先連結tcmalloc再連結libc（或libstdc++），否則，malloc/new函式還是被繫結到原生的libc（或libstdc++）中。延伸：程序載入多個依賴庫時，可以選擇廣度優先遍歷載入，也可以選擇深度優先遍歷載入，不同的載入策略，會導致某些動態庫的載入順序發生變化，如果多個動態庫中含有相同的動態符號，那麼會產生不同的符號繫結結果。但對於tcmalloc來說，只要不顯示連結libc（或libstdc++），一般就沒什麼問題，因為不管廣度優先還是深度優先，tcmalloc必然在libc（libstdc++）之前先被載入。