儘管小項目g ++產生大的二進制文件

Question

也許這是一個常見問題。事實上，我想我幾年前曾問過它......但我不記得答案。

問題是：我有一個由6個源文件組成的項目。他們全部不超過200行代碼。它使用了許多STL容器，stdlib.h和iostream。現在可執行文件的大小約爲800kb ....我想我不應該靜態鏈接庫。如何用GCC做到這一點？在Eclipse CDT中？

編輯： 當我回應我想要的，我認爲這是一個澄清的情況。我想知道的是，爲什麼這樣一個小程序的規模如此之大，以及與靜態，共享庫和它們的不同之處有什麼關係。如果說這是一個太長的故事，可以隨意指出文檔。謝謝

Answer 1

如果您給g ++動態庫名稱，並且不通過-static標誌，它應該動態鏈接。

爲了減小尺寸，您當然可以使用strip二進制，並將-Os（優化大小）優化標誌傳遞給g++。

Answer 2

使用-O3和-s標誌生成最優化的二進制文件。另請參閱此link瞭解更多信息。

如果您正在爲Windows構建，請考慮使用Microsoft編譯器。它總是在該平臺上生成最小的二進制文件。

Answer 3

除非您在makefile中的鏈接器上設置了靜態標誌，否則Eclipse應該默認動態鏈接。

在回答您的編輯：

- 當你靜態鏈接，可執行文件包含每個你鏈接到庫的完整副本。
- 當您動態鏈接時，可執行文件只包含對鏈接庫的引用和掛鉤，這是一個少得多的代碼量。

Answer 4

可執行文件必須包含的不僅僅是您的代碼。

在程序啓動之前，它至少包含一些啓動代碼，設置環境並在必要時加載任何外部庫。

如果您已經靜態鏈接運行時庫，那麼您也會得到包含在可執行文件中的運行時庫。否則，你只會得到一個小的存根，只是足夠大，可以將系統調用重定向到外部運行時。

它可能會根據編譯器設置還包括大量的調試信息和其他非必要的數據。如果優化已啓用，那麼可能也會增加代碼大小。

真正的問題是爲什麼這件事？ 800KB仍然很容易安裝在軟盤上！ 這大部分是一次性成本。這並不意味着如果你寫了兩倍的代碼，它將佔用1600KB。更可能的是，它需要810KB或類似的東西。

不要擔心一次性啓動成本。

Answer 5

要記住的一件事是即使您正在動態鏈接C++庫，使用STL結果在您的可執行文件中有額外的代碼。這是因爲STL是一堆模板，直到您編寫和編譯代碼時纔會實際編譯。由於庫無法預測可能存儲在容器中的內容，因此庫無法爲容器的特定用途包含代碼。與STL中的算法和其他所有內容一樣。

我不是說這絕對是你的可執行文件比你期望的大得多的原因。但這可能是一個因素。

Answer 6

大小通常會導致靜態庫被鏈接到您的應用程序中。

通過編譯爲RELEASE版本，可以減少編譯後的二進制文件的大小，優化爲二進制大小。

可執行文件大小的另一個來源是庫。你說你不使用外部庫，除了STD，所以我相信你將C運行時包含在你的可執行文件中，即靜態鏈接。所以檢查動態鏈接。

IMO你真的不應該擔心，但如果你真的偏執，看看這個：Smallest x86 ELF Hello World

Answer 7

利用Visual C++ 6.0 它支持Windows 95到Windows 7 ，可以編譯成x86平臺，但只適用於Windows。 所以如果你是一個Windows用戶只是堅持使用Windows編譯器而不是GCC，這實際上是sux。大多數人說Visual C++是sux因爲他們是反微軟件。 也記得使用「Visual C++ 6.0」，如果你使用一個新的可能你不能在Windows 95上運行你的文件。我測試了所有這些，這就是爲什麼我說。 GCC產生最大的二進制文件，但Visual C++沒有，英特爾編譯器可以用來節省超過30％的空間，但它需要一個英特爾處理器，除非性能會很糟糕。 你需要記住的另一件事是，當你使用模板時，雖然你看到小行 當你編譯這些函數時會被擴展，所以結果會產生更大的二進制文件。 如果你需要更小的二進制文件，我建議移動到C原因C的實際廣泛使用，但不OO INFACT C是容易比使用C++ 這有一定道理，那麼C++例子

COUT < <的「Hello World」 < < ENDL; printf（「％s」，「Hello World」）;

第二個說打印字段％s表示你輸入一個字符串，所以很容易。 ：P