.dll
o .so
son bibliotecas compartidas (vinculado en tiempo de ejecución), mientras que .a
y .lib
es una biblioteca estática (vinculado en tiempo de compilación). Esto no es una diferencia entre Windows y Linux.
La diferencia es cómo se manejan. Nota: la diferencia es solo en la aduana, cómo se usan. No sería demasiado difícil hacer compilaciones de Linux en Windows y viceversa, excepto que prácticamente nadie hace esto.
Si usamos un dll, o llamamos a una función incluso desde nuestro propio binario, hay una manera simple y clara. Por ejemplo, en C, vemos que:
int example(int x) {
...do_something...
}
int ret = example(42);
Sin embargo, a nivel asm, podría haber muchas diferencias. Por ejemplo, en x86, call
se ejecuta un código de operación y 42
se proporciona en la pila. O en algunos registros. O en cualquier parte. Nadie sabe que antes de escribir el dll , cómo se usará. O cómo los proyectos querrán usarlo, posiblemente escrito con un compilador (¡o en un idioma!) Que ni siquiera existe ahora (o es desconocido para los desarrolladores del dll).
Por ejemplo, de manera predeterminada, tanto C como Pascal colocan los argumentos (y obtienen los valores de retorno) de la pila, pero lo hacen en un orden diferente . También puede intercambiar argumentos entre sus funciones en los registros mediante alguna optimización dependiente del compilador.
Como puede ver correctamente, la costumbre de Windows es que al crear un dll, también creamos un mínimo .a
/ .lib
con él. Esta biblioteca estática mínima es solo un contenedor, los símbolos (funciones) de ese dll se alcanzan a través de ella. Esto hace las conversiones de llamadas de nivel asm requeridas.
Su ventaja es la compatibilidad. Su desventaja es que si solo tiene un .dll, puede tener dificultades para descubrir cómo se llamará a sus funciones. Esto hace que el uso de dlls sea una tarea de hackeo, si el desarrollador del dll no le da el.a
. Por lo tanto, sirve principalmente para fines de cierre, por ejemplo, es más fácil obtener efectivo adicional para los SDK.
Su otra desventaja es que incluso si usa una biblioteca dinámica, necesita compilar este pequeño contenedor estáticamente.
En Linux, la interfaz binaria de los dlls es estándar y sigue la convención C. Por lo tanto, no .a
se requiere y hay compatibilidad binaria entre las bibliotecas compartidas, a cambio no tenemos las ventajas de la costumbre de Microsoft.