Conflictos de símbolos de bibliotecas estáticas y compartidas?

Question

Tengo un proyecto que está trabajando con FreeImage y openCV, actualmente estamos usando el soporte jpeg de ambos (estoy trabajando para solucionarlo, 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 vincular a 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 openCV comienzan a funcionar nuevamente, 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 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ática y una libjpeg compartida generan errores que unen debido a la duplicación símbolos?

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 lo hizo funcionar de nuevo, ni idea de lo que está pasando.

Answer 1

es así

bibliotecas estáticas están recopilados en, bibliotecas dinámicas se cargan en tiempo de ejecución, pero sólo aquellos símbolos que faltan (creo). puede compilar bibliotecas compartidas, y entonces probablemente obtenga una colisión de símbolos.

por lo que opencv utiliza 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.

Answer 2

En general, el vinculador está bien para que se pasen múltiples bibliotecas que resuelvan 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 linker que he usado asume que quiere para usar todos los objetos que especifique, y se quejará si más de uno tiene el mismo símbolo.

Answer 3

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 el enlace estático, y luego no habrá conflictos. Por defecto, todos los símbolos se exportan, ese es el problema.Ver este enlace: http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html