1.1. 地址無關代碼

需要被 Prelink 的 ELF 文件，無論是共享庫還是可執行文件，編譯時必須加 -fpic/-fPIC 參數，生成目標無關地址代碼。對于可執行文件，不能使用 -fpie/-fPIE 加 –pie 生成地址無關可執行文件，否則無法被 prelink。

這個結論是根據上述測試程序得出的，其中的詳細機理有待進一步研究。

1.2. 檢查Prelink 狀態

可以使用 readelf 和 objdump 工具來檢查一個 ELF 文件是否已經被 prelink。例如：

注意觀察到 6~14 行，對比沒有被 prelink 之前的狀態，INIT、FINI、STRTAB、SYMTAB 等 section 的地址已經修改為運行時進程空間的虛擬內存地址。第 30 行，RELACOUNT 表示已經預先進行重定位的符號的數量；第 31 行是 prelink 根據 ELF 所直接依賴的共享庫計算的 MD5 值，該值用于判斷該 ELF 所以來的共享庫是否被修改過；從第 32 行可以看出該 ELF 已被加上 PRELINKED 標記和時間戳。

但是，并非所有被成功 prelink 的 ELF 文件都會加上 PRELINKED 的標記和時間戳。在用 prelink 處理完我們的SDK的后，發現 target_bin 所有的依賴項都有 PRELINKED 標記，target_bin 自身并沒有此標記。但是通過測試其啟動速度，確有巨大的提升，證明 prelink 在 target_bin 上確實發揮了作用。

至于為什么沒有這個標記，暫時還沒有調查清楚，仍待進一步研究。

對于上述情況，通過 objdump 等工具查看ELF文件的 section header，我們仍然可以發現 prelink 處理后留下的蛛絲馬跡。

Prelink 之前，查看 target_bin 的節頭：

Prelink 之后，再次查看節頭：

對比 prelink 前后的節頭信息，我們發現 prelink 后每個節的地址都有了調整，增加了.gnu.liblist ， .gnu.conflict 和 .gnu.prelink_undo 這三個節。同時 .dynstr 節的 size 由 0xa3cb1 增加到了 0xa3e8c。這些都是 prelink 之后 ELF 的 size 有所增大的原因。

1.3. 查看ELF依賴樹

Prelink 的處理過程是從目標 ELF 文件開始，檢查其依賴樹。從葉子節點開始處理，自底向上，直至根節點。若中間任何節點處理異常，則目標文件都無法被 prelink。同理，如果已經被 prelink 處理的 ELF 文件，如果其依賴樹的中任何節點對應的 ELF 文件有更改，則需要從根開始重新 prelink。如果被更改的 ELF 所處的層級較低，被很多可執行文件依賴，則可能整個系統的 ELF 都需要重新進行 Prelink 處理。

可以使用 lddtree 查看 ELF 文件的依賴樹。但是這個工具比較雞肋，只適用于處理本機的 ELF 文件，無法像 prelink 一樣可以在運行時指定 sysroot 和 LD_LIBRARY_PATH。

1.4. 不必要的依賴項

如果 prelink 在處理某個 ELF 文件（記為 A）的過程中，發現 A 并沒有使用其直接依賴的另一個 ELF 文件（記為 B），而 A 又通過 C 間接依賴到 B，并且 B 已經被 prelink 處理。此時，A 將無法被 prelink。

1.5. 動態加載的共享庫

Prelink 對于通過 dlopen 方式打開的共享庫沒有效果。