VC++鏈接器刪除間接依賴於靜態庫

考慮這種情況（在釋放模式的一切）：VC++鏈接器刪除間接依賴於靜態庫

a.lib includes f1() and f2(). 
a.lib is built using /LTCG on VS2015. 
f1() is local without any external function calls. 
f2() calls fc() from b.lib 

b.lib includes fc() and 100s of other functions. 
b.lib is built by a 3rd party, probably not VS. 

main.exe is built only with main.cpp, using /LTCG on VS2015. 
main.exe links to a.lib and b.lib 
main.cpp only calls f1()

現在，當我建立MAIN.EXE，我希望它僅包含F1（）的實現。可執行文件的大小是〜10MB。但是，如果我在a.lib中註釋掉f2（）的實現並重建a.lib，那麼main.exe就會變成200KB。它在兩種情況下都完全相同。

我擔心的是可執行文件的大小，並且暴露了有關b.lib（這不是我自己的庫）的任何不必要的內容。

問題：爲什麼鏈接器不夠智能，不能包含f2（） - > fc（）的定義？而它足夠聰明，不包括b.lib的其餘部分（超過100MB）？

來源

2016-05-18 Alparslan

您可以嘗試使用C/C++/Gy選項構建a.lib並使用鏈接器/ OPT選項鍊接您的可執行文件嗎？ –

/Gy已經爲a.lib定義，對於可執行文件/ OPT：ICF和/ OPT：REF已經啓用。心中有另一個/ OPT嗎？ – Alparslan

鏈接器將拖動所有可能使用的靜態（如錯誤編號映射到字符串），以及所有可能由fc調用的函數以及靜態用於初始化自身的所有函數。

我不擔心公開使用b.lib（假設您已經正確授權），保護知識產權是供應商的問題。

可執行文件的大小是一個真正的問題，但我不認爲你可以對此做很多事情。

來源

2016-05-18 06:13:20

我知道所有與fc有關的東西都被拖入，但我不知道爲什麼它是必要的，那是我的問題。順便說一句，b.lib是正確的許可。但是當我不需要的時候，我不想發佈它的機器代碼，因爲我們使用b.lib來做非常特殊的產品，而a.lib是我們所有產品之間共享的。 – Alparslan

不知道b.lib的內部，我們不能說爲什麼它是所有需要的。 –

你說：「我不想在我不需要的時候發送它的機器代碼，因爲我們使用b.lib來生產非常特殊的產品」，但這對我來說沒有任何意義。您有使用b.lib的許可，在需要時使用它 - 如果某些機器代碼被拖入，爲什麼對您有影響？ –

VC++鏈接器刪除間接依賴於靜態庫

回答

相關問題