Estoy tratando de compilar estáticamente algo y estoy tratando de entender qué son todas estas dependencias. Sé que los archivos .dll son para dependencias dinámicamente vinculadas que serán requeridas por el resultado final, pero ¿qué son los archivos .a y .lib y cuándo los necesita cada uno?¿Cuál es la diferencia entre los archivos .lib y .a?
.a es un archivo de código: compilado pero no vinculado. Deberías vincularlo estáticamente con él durante el paso del enlace final de tu programa.
.lib puede ser el mismo que .a, o una llamada "biblioteca de importación" mágica: un marcador de posición delgada que hace que necesite un .dll en tiempo de ejecución.
Por lo general, .a es para las bibliotecas estáticas y en Linux, mientras que .lib son para el mismo, pero en Windows. Pero, por supuesto, es solo una convención.
En los sistemas Unix, tiene los archivos .a. Estos son archivos simples de archivos de objetos (.o).
En Windows, hay .lib archivos, que son casi lo mismo, pero para Windows en lugar de Unix.
Una sutileza adicional es que para vincular un código con un archivo DLL (en Windows), debe vincularlo con un archivo .lib que contiene envolturas simples que invocan el archivo DLL. En el sistema Unix, tradicionalmente, no hay necesidad de tales envoltorios (el enlazador es lo suficientemente inteligente como para generarlos sobre la marcha).
Gracias por esta respuesta, descubrí que estaba tratando de compilar con una bandera de Windows en alguna parte. :) –
¿Hay alguna diferencia entre .a creado en Windows y Unix? – samnaction
Algo que no veo mencionar aquí todavía es el hecho sorprendente de que, al menos algunas veces, los archivos .a y .lib son , en realidad tienen el mismo formato binario. Aunque no pude encontrar nada que diga tanto en el sitio web de mingw, noté que al intentar obtener el compilador de clúster de 64 bits de MS Visual C++ para vincularlo en un archivo .dll producido utilizando el compilador mingw-w64 g ++, felizmente aceptado la línea de comandos
cl /EHsc /Ipath\to\include gmp_test.cpp path\to\lib\libgmp.dll.a
y el archivo .exe resultante funcionó correctamente tan pronto como pongo una copia del archivo .dll correspondiente en el directorio actual. (Murmuró la advertencia "Advertencia de línea de comando D9024: tipo de archivo de origen no reconocido 'ruta \ a \ lib \ gmp-6.0.0 \ lib \ libgmp.dll.a', archivo de objeto asumido".)
Prueba adicional es que el comando Linux file informó "archivo ar actual" para varios archivos de cada extensión (.lib o .a) que probé.
Estoy compilando el marco de QT con una biblioteca .a OpenSSL, pero de alguna manera mi ejecutable final producido por QT aún requiere un dll de OpenSSL externo para poder ejecutarlo. ¿Tienes alguna idea de cómo podría ser este el caso dado que estoy usando una biblioteca .a? – Nantucket
¿Cómo se compilaron los contenidos de OpenSSL .a? ¿Cómo enlazas tu último ejecutable? – crazyscot
No estoy seguro acerca de "requerir un .dll en tiempo de ejecución". No necesitará .dll si su proyecto está utilizando bibliotecas estáticas .lib (a menos que existan dependencias .dll que no haya identificado correctamente). – ha9u63ar