c++ - librerías - diferencia entre biblioteca y libreria en programacion
¿Conflictos de símbolos de bibliotecas estáticas y compartidas? (3)
Tengo un proyecto trabajando en eso usando FreeImage y openCV, actualmente estamos usando el soporte jpeg de ambos (estoy trabajando para solucionar eso, pero por ahora debe quedarse). De todos modos, FreeImage compila libjpeg 7.0 en sus bibliotecas estáticas, y la biblioteca highgui de openCV lo vincula como una biblioteca compartida (en mi sistema, Ubuntu 9, tengo libjpeg 6.2 instalado).
Se vinculan a una biblioteca final que se utiliza para enlazar con varios programas, envoltorios Java, etc. Todo eso funciona bien, no hay conflictos de símbolos ni nada durante el tiempo de compilación / enlace. Sin embargo, cuando voy a abrir una imagen usando la función openCV cvLoadImage, muere al leer el encabezado, muy probablemente debido a diferencias entre los encabezados en 6.2 y 7.0.
Si desvincula FreeImage (y comenta el código que lo requiere), las llamadas a openCV vuelven a funcionar, por lo que los símbolos libjpeg estáticos de FreeImage están en conflicto con los símbolos que se cargarían desde la biblioteca compartida de libjpeg. Lo que no puedo entender es por qué mi compilador no está arrojando un error durante la vinculación debido a los dos conjuntos de símbolos libjpeg. Además, he intentado reemplazar el encabezado jpeglib.h de mi sistema con la versión 7.0 temporalmente para ver si openCV compilado con eso se sincronizaría con los símbolos que Freeimage trae a la mesa, en vano parece.
Por último, puse un printf en jpeg_read_header en el libjpeg que compila freeimage, y lo reconstruí para ver si openCV está usando la definición libjpeg de Freeimage. No se imprimió así que tengo que asumir que no.
Así que supongo que mis preguntas son
1) ¿Por qué no vincular un libjpeg estático y un libjpeg compartido generan errores de enlace debido a símbolos duplicados?
2) ¿Alguien sabe por qué estas dos cosas están en conflicto entre sí?
Editar: la compilación de openCV en modo de depuración y luego en el modo regular de nuevo parece haber dejado algo suelto y hacer que funcione de nuevo, ni idea de lo que está pasando.
Debe modificar las opciones de vinculación para exportar solo los símbolos que desee, y luego todos los símbolos en conflicto se ocultarán internamente en los enlaces estáticos, y luego no habrá conflictos. Por defecto, todos los símbolos se exportan, ese es el problema. Vea este enlace: http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Bibraries.html
En términos generales, el enlazador está bien si se le pasan múltiples bibliotecas que resuelven el mismo símbolo (s). Simplemente usa el primero que encuentra. El orden de las bibliotecas en su línea de comando del enlazador determinará cuál de ellas "gana".
Esto, por cierto, NO es cierto para los archivos de objeto. Cada vinculador que he usado asume que quiere usar todos los objetos que especifique, y se quejará si más de uno tiene el mismo símbolo.
es así
Las bibliotecas estáticas están compiladas, las bibliotecas dinámicas se cargan durante el tiempo de ejecución, pero solo aquellos símbolos que faltan (creo). puede compilar bibliotecas compartidas, y entonces probablemente obtenga una colisión de símbolos.
entonces opencv usa símbolos que están compilados, ya que ya están presentes, en lugar de los de bibliotecas dinámicas. terminas usando símbolos estáticos, posiblemente con diferentes firmas, desde prospectivo de opencv.