2010-04-15 11 views
428

¿Cuál es la diferencia entre bibliotecas estáticas y compartidas?¿Diferencia entre bibliotecas estáticas y compartidas?

Uso Eclipse y hay varios tipos de proyectos, incluidas las bibliotecas estáticas y las bibliotecas compartidas? ¿Uno tiene una ventaja sobre el otro?

+3

Wikipedia tiene una [buena descripción] (http://en.wikipedia.org/wiki/Library_%28computing%29) de la distinción entre bibliotecas estáticas, dinámicas y compartidas. –

Respuesta

595

bibliotecas compartidas son .so (o en Windows .dll, o en OS X .dylib) archivos. Todo el código relacionado con la biblioteca se encuentra en este archivo, y los programas que lo utilizan lo hacen referencia en el tiempo de ejecución. Un programa que usa una biblioteca compartida solo hace referencia al código que usa en la biblioteca compartida.

Las bibliotecas estáticas son archivos .a (o en Windows .lib). Todo el código relacionado con la biblioteca está en este archivo y está directamente vinculado al programa en tiempo de compilación. Un programa que utiliza una biblioteca estática toma copias del código que utiliza de la biblioteca estática y lo hace parte del programa. [Windows también tiene.archivos lib que se utilizan para hacer referencia a archivos .dll, pero actúan de la misma manera que el primero].

Existen ventajas y desventajas en cada método.

Las bibliotecas compartidas reducen la cantidad de código que se duplica en cada programa que hace uso de la biblioteca, manteniendo los binarios pequeños. También le permite reemplazar el objeto compartido por uno que sea funcionalmente equivalente, pero puede haber agregado beneficios de rendimiento sin la necesidad de recompilar el programa que lo usa. Las bibliotecas compartidas, sin embargo, tendrán un pequeño costo adicional para la ejecución de las funciones, así como un costo de carga en tiempo de ejecución, ya que todos los símbolos de la biblioteca deben estar conectados a las cosas que usan. Además, las bibliotecas compartidas se pueden cargar en una aplicación en tiempo de ejecución, que es el mecanismo general para implementar sistemas de complemento binarios.

Las bibliotecas estáticas aumentan el tamaño general del binario, pero significa que no necesita llevar consigo una copia de la biblioteca que se está utilizando. Como el código está conectado en tiempo de compilación, no hay costos adicionales de carga en tiempo de ejecución. El código está simplemente allí.

Personalmente, prefiero las bibliotecas compartidas, pero uso las bibliotecas estáticas cuando necesito asegurarme de que el binario no tiene muchas dependencias externas que pueden ser difíciles de cumplir, como versiones específicas de la biblioteca estándar de C++ o versiones específicas de Boost Biblioteca C++.

+2

"reemplazar el objeto compartido con ... funcionalmente equivalente, pero puede [mejorar] el rendimiento": específicamente , funcionalidad de llamada de interlocutor equivalente en el uso semántico de la API (interfaz de programación de aplicaciones: firmas de funciones y variables, incluidos los tipos), pero la funcionalidad del lado de implementación puede diferir en más que perf .: por ejemplo, la función siempre registra en el archivo -> también iniciar sesión en TCP servidor: puerto esperado en $ MY_APP_LOG_SERVER. –

+1

"[.sos incurrir en un] pequeño costo adicional para la ejecución de las funciones "- that's * possible * (si los grupos de funciones/pedidos se han optimizado para la localidad de caché en el enlace estático o debido a las rarezas en OS/loader/compiler/architecture como perf de cross-segment/large-pointer perf. sanciones), pero en muchas arquitecturas/configuraciones de compilador, el vinculador dinámico repara la llamada para crear exactamente los mismos códigos de operación de la máquina que llama. –

+2

"Como el código está conectado en tiempo de compilación, no hay costos adicionales de carga en tiempo de ejecución. El código simplemente está allí". - sí y no ... está todo en la imagen ejecutable lista para ser localizada si la ejecución lo requiere, pero, a partir de una situación en la que el programa no se ejecutó lo suficiente para estar en caché, es posible con bibliotecas compartidas (a veces o seguro) que el sistema operativo, un controlador u otro programa en ejecución ya habrá cargado la misma biblioteca compartida que su aplicación desea usar, en cuyo caso puede estar en caché y su programa puede iniciarse y ejecutarse más rápido. –

24

Para una biblioteca estática, el código se extrae de la biblioteca por el vinculador y se utiliza para compilar el ejecutable final en el punto en que compila/crea su aplicación. El ejecutable final no tiene dependencias en la biblioteca en tiempo de ejecución

Para una biblioteca compartida, el compilador/vinculador comprueba que los nombres que vinculan existen en la biblioteca cuando se genera la aplicación, pero no mueve su código a la aplicación. En tiempo de ejecución, la biblioteca compartida debe estar disponible.

El lenguaje de programación C en sí no tiene ningún concepto de bibliotecas estáticas o compartidas: son completamente una característica de implementación.

Personalmente, prefiero usar bibliotecas estáticas, ya que simplifica la distribución de software. Sin embargo, esta es una opinión sobre la cual mucha sangre (figurativa) ha sido derramada en el pasado.

+3

+1 para "El lenguaje de programación C en sí no tiene ningún concepto de bibliotecas estáticas o compartidas, son completamente una característica de implementación." – Tiger

14

La ventaja más significativa de las bibliotecas compartidas es que solo hay una copia del código cargado en la memoria, sin importar cuántos procesos estén usando la biblioteca. Para las bibliotecas estáticas, cada proceso obtiene su propia copia del código. Esto puede conducir a un gran desperdicio de memoria.

OTOH, una ventaja de las bibliotecas estáticas es que todo está incluido en su aplicación. Por lo tanto, no tiene que preocuparse de que el cliente tenga la biblioteca (y la versión) correctas disponibles en su sistema.

+1

imagen ejecutable es más grande en el disco, así como en la memoria, cuando se utilizan libs estáticas. – JustJeff

+0

Eso es correcto, eso es a lo que me refería cuando dije todo está incluido en su aplicación – Jasmeet

46

simplificado:

  • vinculación estática: una gran ejecutable
  • La vinculación dinámica: un pequeño ejecutable más uno o más archivos de biblioteca (.dll en Windows, .so en Linux, o .dylib en MacOS)
26

Las bibliotecas estáticas se compilan como parte de una aplicación, mientras que las bibliotecas compartidas no lo son. Cuando distribuye una aplicación que depende de bibliotecas compartidas, las bibliotecas, p. Ej. dll's en MS Windows necesitan ser instalados.

Las ventajas de las bibliotecas estáticas es que no hay dependencias requeridas para el usuario que ejecuta la aplicación, p. no tienen que actualizar su DLL de lo que sea ... Las desventajas son que su aplicación es de mayor tamaño porque la envía con todas las bibliotecas que necesita.

Así como que conduce a aplicaciones más pequeñas, las bibliotecas compartidas ofrecen al usuario la posibilidad de utilizar su propio quizás mejor versión de las bibliotecas, en lugar de depender de uno que es parte de la aplicación

+2

DLL infierno como se ha conocido – gheese

+1

"Las bibliotecas estáticas se compilan como parte de una aplicación" ... las bibliotecas estáticas se compilan como bibliotecas estáticas y se vinculan como parte de una aplicación – user463035818

323

Una biblioteca estática es como una librería, y una biblioteca compartida es como ... una biblioteca. Con la primera, obtienes tu propia copia del libro/función para llevar a casa; con este último, usted y todos los demás van a la biblioteca para usar el mismo libro/función. Por lo tanto, cualquiera que quiera usar la biblioteca (compartida) necesita saber dónde está, porque tiene que "obtener" el libro/función. Con una biblioteca estática, el libro/función es suya, y la mantiene dentro de su hogar/programa, y ​​una vez que la tiene, no le importa dónde o cuándo la recibió.

2

En la parte superior de todas las otras respuestas, una cosa no mencionado todavía se desacoplamiento:

se os puede decir acerca de un código de producción del mundo real, que he estado tratando con:

Un software muy grande, hecho de> 300 proyectos (con Visual Studio), la mayoría construye como lib estática y finalmente todos se unen en un gran ejecutable, terminas con los siguientes problemas:

-El tiempo de enlace es extremadamente largo. Puede terminar en más de 15 minutos de enlace, por ejemplo, 10 segundos del tiempo de compilación . Algunas herramientas están sobre sus rodillas con un ejecutable tan grande, como las herramientas de verificación de memoria que deben instrumentar el código. Podrías caer en límites que han sido vistos como tontos.

Más problemático es el desacoplamiento de su software: en este ejemplo del mundo real, los archivos de los encabezados de cada proyecto eran alcanzables desde cualquier otro proyecto. Como consecuencia, fue extremadamente fácil para un desarrollador agregar dependencias; simplemente se trataba de incluir el encabezado, porque el enlace al final siempre encontrará símbolos. Termina con horribles dependencias de ciclismo y desorden completo.

Con la biblioteca compartida, es un poco de trabajo adicional porque el desarrollador debe editar el sistema de compilación del proyecto para agregar la biblioteca dependiente. Observé que el código de biblioteca compartida tiende a ofrecer una API de código más limpia.

Cuestiones relacionadas