g ++ produce grandes binarios a pesar del pequeño proyecto

Question

Probablemente esta sea una pregunta común. De hecho, creo que lo pregunté hace años ... pero no recuerdo la respuesta.

El problema es: tengo un proyecto que se compone de 6 archivos fuente. Todos ellos no más de 200 líneas de código. Utiliza muchos contenedores STL, stdlib.h e iostream. Ahora el ejecutable tiene un tamaño de alrededor de 800 kb ... Supongo que no debería vincular estáticamente las bibliotecas. ¿Cómo hacer esto con GCC? ¿Y en Eclipse CDT?

EDITAR: A medida que respondo lejos de lo que quiero, creo que es el caso para una aclaración. Lo que quiero saber es por qué un programa tan pequeño es tan grande y cuál es la relación con las bibliotecas estáticas compartidas y su diferencia. Si es una historia demasiado larga para contar, no dudes en dar consejos a los documentos. Gracias

Answer 1

Si le da nombres a la biblioteca dinámica de g ++, y no pasa la bandera -static, debería vincularse dinámicamente.

Para reducir el tamaño, por supuesto, puede strip el binario y pasar el indicador de optimización -Os (optimizar para el tamaño) a g++.

Answer 2

Una cosa para recordar es que el uso de STL resulta en tener ese código adicional en su ejecutable incluso si está enlazando dinámicamente con la biblioteca C ++. Esto se debe al hecho de que el STL es un conjunto de plantillas que no se compilan realmente hasta que escribe y compila su código. Dado que la biblioteca no puede anticipar lo que podría almacenar en un contenedor, no hay forma de que la biblioteca ya contenga el código para ese uso particular del contenedor. Lo mismo ocurre con los algoritmos y todo lo demás en el STL.

No estoy diciendo que esta sea definitivamente la razón por la cual su ejecutable es mucho más grande de lo que espera. Pero puede ser un factor.

Answer 3

Eclipse debería vincularse dinámicamente de forma predeterminada, a menos que haya configurado el indicador estático en el vinculador en su archivo MAKE.

En respuesta a su EDITAR:

: cuando realiza un enlace estático, el archivo ejecutable contiene una copia completa de cada biblioteca a la que se ha vinculado.
-cuando se vincula dinámicamente, el ejecutable solo contiene referencias y enlaces a las bibliotecas vinculadas, que es una cantidad de código mucho más pequeña.

Answer 4

El ejecutable debe contener más que solo su código.

Como mínimo, contiene un código de inicio que configura el entorno y, si es necesario, carga las bibliotecas externas antes de que se inicie el programa.

Si ha vinculado estáticamente la biblioteca de tiempo de ejecución, también se incluye en su ejecutable. De lo contrario, solo obtendrá un trozo pequeño, lo suficientemente grande como para redirigir las llamadas del sistema al tiempo de ejecución externo.

Puede, dependiendo de la configuración del compilador, también incluir mucha información de depuración y otros datos no esenciales. Si las optimizaciones están habilitadas, también puede haber aumentado el tamaño del código.

La verdadera pregunta es ¿por qué importa esto ? ¡800 KB todavía cabe fácilmente en un disquete! La mayor parte de esto es un costo único. no significa que si escribe el doble de código, ocupará 1600 KB. Lo más probable es que tome 810 KB o algo así.

No se preocupe por los costos de inicio únicos.

Answer 5

Utilice los indicadores -O3 y -s para producir el binario más optimizado. Consulte también este enlace para obtener más información.

Si está compilando para Windows, considere usar el compilador de Microsoft. Siempre produce el binario más pequeño en esa plataforma.

Answer 6

El tamaño generalmente hace que las bibliotecas estáticas se vinculen a su aplicación.

Puede reducir el tamaño del binario compilado compilando en versiones RELEASE, con optimizaciones para el tamaño binario.

Otra fuente de tamaño ejecutable son las bibliotecas. Dijiste que no usas bibliotecas externas, excepto STD, así que creo que estás incluyendo C Runtime con tu ejecutable, es decir, vinculando estáticamente. así que verifique la vinculación dinámica.

En mi opinión, realmente no debería preocuparse por eso, pero si es realmente paranoico, verifique esto: El más pequeño x86 ELF Hola mundo

Answer 7

usa Visual C ++ 6.0 Es compatible con Windows 95 a Windows 7. y se puede compilar como plataformas x86 pero solo para Windows. así que si usted es un usuario de Windows, quédese con compiladores de Windows que no sean GCC, que en realidad es sux. La mayoría de las personas que dicen que Visual C ++ es sux porque son Anti-Microsofters. también recuerde usar " Visual C ++ 6.0 " si usa uno más nuevo, probablemente no pueda ejecutar sus archivos en Windows 95. He probado todas esas cosas por eso dije. GCC produce los binarios más grandes, pero Visual C ++ no, Intel Compiler puede usar para ahorrar más del 30% de espacio, pero exige un procesador Intel a menos que el rendimiento sea horrible. Otra cosa que debes recordar es cuando usas plantillas aunque veas líneas pequeñas cuando compila esas funciones se expandirían para que el resultado sea hacer binarios más grandes. si necesita binarios más pequeños, sugiero pasar a C porque C es realmente muy utilizado pero no OO De hecho, C es fácil de usar que C ++ esto tiene sentido, entonces el ejemplo de C ++

cout < < " Hola Mundo " < < endl printf ("% s ", " Hola Mundo ");

el segundo dice campo de impresión% s significa que escribe una cadena para que sea fácil. : P