g ++ produce grandi binari nonostante un piccolo progetto

Question

Probabilmente questa è una domanda comune. In effetti penso di averlo chiesto anni fa ... ma non ricordo la risposta.

Il problema è: ho un progetto composto da 6 file sorgente. Tutti non più di 200 righe di codice. Utilizza molti contenitori STL, stdlib.h e iostream. Ora l'eseguibile ha una dimensione di circa 800kb ... Immagino che non dovrei collegare staticamente le librerie. Come fare questo con GCC? E in Eclipse CDT?

EDIT: Mentre rispondo a ciò che voglio, penso che sia il caso di un chiarimento. Quello che voglio sapere è perché un programma così piccolo ha dimensioni così grandi e qual è il rapporto con le librerie statiche condivise e la loro differenza. Se è una storia troppo lunga da raccontare, sentiti libero di dare indicazioni ai documenti. Grazie

Answer 1

Se dai nomi di libreria dinamica g ++ e non passi il flag -static, dovrebbe collegarsi dinamicamente.

Per ridurre le dimensioni, puoi ovviamente strip il file binario e passare il flag di ottimizzazione -Os (ottimizza per dimensioni) su g++.

Answer 2

Una cosa da ricordare è che l'uso dell'STL porta ad avere quel codice extra nel tuo eseguibile anche se stai collegando dinamicamente con la libreria C ++. Questo in virtù del fatto che STL è un gruppo di modelli che non vengono effettivamente compilati finché non si scrive e si compila il codice. Poiché la libreria non è in grado di anticipare ciò che è possibile archiviare in un contenitore, non è possibile che la libreria contenga già il codice per quel particolare utilizzo del contenitore. Lo stesso vale per gli algoritmi e tutto il resto nella STL.

Non sto dicendo che questo è sicuramente il motivo per cui il tuo eseguibile è molto più grande di quanto ti aspetti. Ma potrebbe essere un fattore.

Answer 3

Eclipse dovrebbe essere collegato dinamicamente per impostazione predefinita, a meno che tu non abbia impostato il flag statico sul linker nel tuo makefile.

In risposta al tuo EDIT:

-quando si collega staticamente, l'eseguibile contiene una copia completa di ogni libreria a cui si è collegati.
-quando si collega dinamicamente, l'eseguibile contiene solo riferimenti e hook alle librerie collegate, che è una quantità molto più piccola di codice.

Answer 4

L'eseguibile deve contenere più di un semplice codice.

Per lo meno, contiene del codice di avvio, impostazione dell'ambiente e, se necessario, caricamento di eventuali librerie esterne, prima dell'avvio del programma.

Se hai collegato staticamente la libreria di runtime, puoi includerla anche nel tuo eseguibile. Altrimenti ottieni solo un piccolo stub, abbastanza grande da reindirizzare le chiamate di sistema al runtime esterno.

Può, a seconda delle impostazioni del compilatore, includere anche molte informazioni di debug e altri dati non essenziali. Se le ottimizzazioni sono abilitate, è possibile che anche le dimensioni del codice siano aumentate.

La vera domanda è perché è importante ? 800 KB si adatta ancora facilmente su un disco floppy! La maggior parte di questo è un costo una tantum. non significa che se si scrive il doppio del codice, ci vorranno 1600 KB. Più probabilmente, ci vorranno 810 KB o qualcosa del genere.

Non preoccuparti dei costi di avvio una tantum.

Answer 5

Usa i flag -O3 e -s per produrre il binario più ottimizzato. Vedi anche questo link per ulteriori informazioni.

Se stai compilando per Windows, considera l'utilizzo del compilatore Microsoft. Produce sempre il binario più piccolo su quella piattaforma.

Answer 6

Le dimensioni in genere comportano il collegamento di librerie statiche nell'applicazione.

È possibile ridurre le dimensioni del file binario compilato compilando versioni RELEASE, con ottimizzazioni alla dimensione binaria.

Un'altra fonte di dimensioni eseguibili sono le librerie. Hai detto che non usi librerie esterne, ad eccezione di STD, quindi credo che tu stia includendo C Runtime con il tuo eseguibile, cioè collegando staticamente. quindi controlla il collegamento dinamico.

IMO non dovresti davvero preoccupartene, ma se sei davvero paranoico, controlla questo: ELF x86 più piccolo Ciao mondo

Answer 7

usa Visual C ++ 6.0 supportato da Windows 95 a Windows 7. e può essere compilato come piattaforme x86 ma solo per Windows. quindi, se sei un utente Windows, usa solo compilatori di Windows diversi da GCC, che in realtà è sux. La maggior parte delle persone che affermano che Visual C ++ è sux perché sono Anti-Microsters. ricorda anche di usare " Visual C ++ 6.0 " se ne usi uno più recente, probabilmente non puoi eseguire i tuoi file su Windows 95. Ho testato tutte quelle cose che è il motivo per cui ho detto. GCC produce binari più grandi, ma Visual C ++ no, Intel Compiler può usare per risparmiare più del 30% di spazio, ma richiede un processore Intel a meno che le prestazioni non siano orribili. un'altra cosa che devi ricordare è quando usi i modelli anche se vedi delle piccole linee quando si compila, tali funzioni vengono espanse in modo da ottenere binari più grandi. se hai bisogno di binari più piccoli ti suggerisco di passare a C perché C è effettivamente ampiamente usato ma non OO infatti C è facile da usare rispetto a C ++ questo ha senso allora esempio C ++

cout < < " Hello World " lt &; lt &; endl; printf ("% s ", " Ciao mondo ");

il secondo dice che il campo di stampa% s significa che si digita una stringa in modo che sia facile. : P