son - ¿Por qué crear un archivo.a desde.o para la vinculación estática?
que es marcar en archivo (6)
Cada vez que me hacen esta pregunta (por parte de los integrantes de mi equipo), "¿por qué (o a veces incluso un ''¿qué es'')?., Utilizo la siguiente respuesta que usa el .zip como una analogía.
"Un dotAy es como un archivo zip de todos los dotOhs que querría vincular mientras construye su exe / lib. Ahorros en el espacio en disco, más uno no necesita escribir nombres de todos los dotOhs involucrados".
Hasta ahora, esto parece haberlos hecho entender. ;)
Considere este código:
one.c:
#include <stdio.h>
int one() {
printf("one!/n");
return 1;
}
dos.c:
#include <stdio.h>
int two() {
printf("two!/n");
return 2;
}
prog.c
#include <stdio.h>
int one();
int two();
int main(int argc, char *argv[])
{
one();
two();
return 0;
}
Quiero unir estos programas juntos. Así que hago esto:
gcc -c -o one.o one.c
gcc -c -o two.o two.c
gcc -o a.out prog.c one.o two.o
Esto funciona bien.
O podría crear una biblioteca estática:
ar rcs libone.a one.o
ar rcs libtwo.a two.o
gcc prog.c libone.a libtwo.a
gcc -L. prog.c -lone -ltwo
Entonces, mi pregunta es: ¿por qué usaría la segunda versión, aquella en la que creé los archivos ".a", en lugar de vincular mis archivos ".o"? Ambos parecen estar vinculados estáticamente, así que ¿hay alguna ventaja o diferencia arquitectónica entre uno y otro?
La diferencia estaría en el tamaño del ejecutable, aunque tal vez no sea para su ejemplo.
Al enlazar a una biblioteca, solo se incorporan los bits que utiliza su ejecutable. Al vincular un archivo de objeto, tomas todo el asunto.
Por ejemplo, si su ejecutable tenía que incluir cada función matemática en la biblioteca matemática cuando solo usa una, sería mucho más grande de lo necesario y contendría una gran cantidad de código no utilizado.
Es interesante contrastar esto con el modelo de enlace dinámico de Windows. Allí, el sistema operativo tiene que cargar todas las Dlls (bibliotecas vinculadas dinámicamente) por completo que utiliza su ejecutable, lo que podría llevar a una gran cantidad de RAM. La ventaja de este modelo es que su ejecutable es en sí mismo más pequeño, y las Dlls vinculadas pueden estar ya en la memoria utilizada por otro ejecutable, por lo que no es necesario que se carguen nuevamente.
En el enlace estático, las funciones de la biblioteca se cargan por separado para cada ejecutable.
La principal ventaja es que cuando tiene que vincular, puede especificar una biblioteca en lugar de todos los archivos de objetos separados. También hay una pequeña ventaja en la gestión de los archivos, al tratar con una biblioteca en lugar de un grupo de archivos de objetos. En un momento dado, esto también dio un ahorro significativo en espacio de disco, pero los precios actuales del disco duro hacen que eso sea menos importante.
Normalmente, las bibliotecas son colecciones de archivos de objetos que se pueden usar en varios programas.
En tu ejemplo no hay ventaja, pero podrías haberlo hecho:
ar rcs liboneandtwo.a one.o two.o
Entonces enlazar tu programa se vuelve más simple:
gcc -L. prog.c -loneandtwo
Es realmente una cuestión de embalaje. ¿Tiene un conjunto de archivos de objetos que naturalmente forman un conjunto de funcionalidades relacionadas que pueden reutilizarse en múltiples programas? Si es así, entonces se pueden archivar sensiblemente en una biblioteca estática, de lo contrario probablemente no haya ninguna ventaja.
Hay una diferencia importante en el paso final del enlace. Todos los archivos de objetos que haya vinculado se incluirán en el programa final. Los archivos de objetos que se encuentran en las bibliotecas solo se incluyen si ayudan a resolver cualquier símbolo indefinido en otros archivos de objetos. Si no lo hacen, no estarán vinculados al ejecutable final.
Puede colocar una colección de archivos en un archivo (.a) para reutilizarlos posteriormente. La biblioteca estándar es un buen ejemplo.
A veces tiene sentido organizar grandes proyectos en bibliotecas.
Técnicamente, el resultado es exactamente el mismo. Por lo general, crea bibliotecas para funciones de utilidad, por lo que en lugar de alimentar al enlazador con docenas de archivos de objetos, solo tiene que vincular la biblioteca.
Por cierto, no tiene ningún sentido crear un archivo .a que contenga solo un archivo .o.