c++ - make shared library gcc
¿Cuál es la diferencia entre los archivos.o.a y.so? (3)
.so son archivos de biblioteca compartidos. .a son archivos de biblioteca estática.
Puede enlazar estáticamente a las bibliotecas .a y vincular y cargar dinámicamente los archivos .so en tiempo de ejecución, siempre que compile y vincule de esa manera.
.o son archivos de objetos (se compilan a partir de archivos * .c y se pueden vincular para crear archivos ejecutables, .a o .so. Lea más sobre esto here
Sé que .o son archivos de objetos, .a son bibliotecas estáticas y .so son bibliotecas dinámicas? ¿Cuál es su significado físico? ¿Cuándo puedo usar un poco y cuándo no?
Las bibliotecas estáticas son archivos que contienen el código objeto de la biblioteca, cuando se vinculan a una aplicación que el código se compila en el ejecutable.
Las bibliotecas compartidas son diferentes en que no se compilan en el ejecutable. En su lugar, el enlazador dinámico busca algunos directorios en busca de las bibliotecas que necesita y luego las carga en la memoria. Más de un ejecutable puede usar la misma biblioteca compartida al mismo tiempo, lo que reduce el uso de memoria y el tamaño del ejecutable. Sin embargo, hay más archivos para distribuir con el ejecutable. Debe asegurarse de que la biblioteca esté instalada en el sistema del usuario en algún lugar donde el vinculador pueda encontrarla, el enlace estático elimina este problema, pero genera un archivo ejecutable más grande.
.a es un "archivo". Aunque un archivo puede contener cualquier tipo de archivo, en el contexto de la cadena de herramientas GNU, es una biblioteca de archivos de objetos (otras cadenas de herramientas, especialmente en Windows, usan .lib para el mismo propósito, pero el formato de estos no suele ser un propósito general archivo, y a menudo específico para la cadena de herramientas). Es posible extraer archivos de objetos individuales de un archivo, que es esencialmente lo que hace el enlazador cuando usa la biblioteca.
.o es un archivo objeto. Este es un código que se compila a un código de máquina pero que no está (típicamente) completamente vinculado; puede tener referencias no resueltas a los símbolos definidos en otros archivos de objetos (en una biblioteca o individualmente) generados por una compilación separada. Los archivos de objetos contienen metadatos para admitir la vinculación con otros módulos y, opcionalmente, también para la depuración simbólica a nivel de origen (por ejemplo, en GDB). Otras cadenas de herramientas, de nuevo típicamente en Windows, usan la extensión .obj lugar de .o .
.so es una biblioteca de objetos compartidos (o solo una biblioteca compartida). Esto se vincula dinámicamente a un ejecutable cuando se inicia un programa en lugar de vincularse estáticamente en el momento de la compilación. Permite ejecutables más pequeños y una única instancia de biblioteca de objetos para ser utilizada por varios ejecutables. Las API de los sistemas operativos suelen ser bibliotecas compartidas y, por lo general, también se usan en GNU por razones de licencia para separar el código LGPL del código propietario de código cerrado, por ejemplo (no soy un abogado: no hago declaraciones sobre la legitimidad de este enfoque en cualquier situación particular). A diferencia de los archivos .o o .a , los archivos .so utilizados por una aplicación deben estar disponibles en el sistema de tiempo de ejecución. Otros sistemas (nuevamente, típicamente Windows) usan .dll (biblioteca de enlace dinámico) para el mismo propósito.
Tal vez sea útil comprender que los archivos .o están vinculados antes que el código objeto en los archivos .a , de modo que si la resolución de un símbolo es satisfecha por un archivo .o , no se vinculará ninguna implementación de la biblioteca, lo que le permite esencialmente reemplazar las implementaciones de la biblioteca con su propios, y también para implementaciones de bibliotecas para llamar código definido por el usuario, por ejemplo, un marco de GUI podría llamar un punto de entrada de la aplicación.