sirve - Vincular una biblioteca compartida con una biblioteca estática: ¿debe compilarse la biblioteca estática de forma diferente a como lo hace si una aplicación la vincula?
que es una libreria en programacion y para que sirve (3)
Como un enfoque alternativo, envíe dos bibliotecas: la compartida y la estática con la que se está enlazando. Deben enlazar en el ejecutable final correctamente.
Al menos en Linux y Solaris, las bibliotecas estáticas son en realidad solo un montón de .o compilados agrupados en un gran archivo. Cuando se compila una biblioteca estática, generalmente el indicador -fpic se omite, por lo que el código generado depende de la posición.
Ahora diga que mi biblioteca estática es B. Lo construí y tengo el archivo .a resultante, que en realidad es solo un globo de todos los archivos .o dependientes de la posición. Ahora tengo una biblioteca compartida que me gustaría compilar, A, y quiero que vincule estáticamente B. Cuando construyo A, naturalmente, usaré el indicador -fpic para que la posición del código generado sea independiente. Pero si vinculo con B, ¿no estoy mezclando archivos de objetos dependientes de posición y de posición independiente?
Recibo muchos errores de reubicación de texto a menos que también especifique -mimpure-text, y creo que esta puede ser la causa. Parece que cuando compilo una biblioteca, realmente necesito compilarla 3 veces, una versión compartida, una versión estática y una versión estática que se puede usar por libs compartidas. Estoy en lo cierto Podría seguir usando -mimpure-text pero la página de manual de g ++ dice que si lo hace, el objeto no termina siendo compartido (no está claro si está todo compartido o solo las partes estáticamente vinculadas, ¿alguien sabe?) .
Hago lo siguiente en la etapa de enlace para la versión de la biblioteca de objetos compartidos de una biblioteca estática: g ++ -shared -o libshared.so -Wl, - whole-archive -fPIC -lstatic -Wl, - no-whole-archive. Dado que --whole-archive vincula cada objeto en una (lista de) libs estáticas (de la forma libstatic.a) Creo que precede a que (lista) con -fPIC es todo lo que el OP necesita hacer.
No tiene que usar el código PIC en objetos compartidos (ya que descubrió que puede usar la opción -mimpure-text para permitir eso).
Dicho esto, el código no PIC en objetos compartidos es más pesado. Con el código PIC, las páginas de texto en la memoria son simplemente asignaciones de memoria directas de las páginas de texto en el disco. Esto significa que si varios procesos utilizan el objeto compartido, pueden compartir la página de memoria.
Pero si no tiene código PIC, cuando el vinculador de tiempo de ejecución carga el objeto compartido, tendrá que aplicar correcciones a las páginas de texto. Esto significa que cada proceso que usa el objeto compartido tendrá su propia versión única de cualquier página de texto que tenga una corrección (incluso si el objeto compartido se carga en la misma dirección que la copia en escritura, solo se da cuenta de que la página estaba modificado y no que se haya modificado de la misma manera).
Para mí, el problema importante es si tendrá simultáneamente varios procesos en ejecución para que cada uno cargue el objeto compartido. Si lo hace, definitivamente vale la pena asegurarse de que todo el código dentro del SO sea PIC.
Pero si ese no es el caso y solo un proceso tiene el objeto compartido cargado, no es tan crítico.