c++ - que - tipos de bibliotecas informatica

¿Cómo puedo enlazar(o solucionar) dos bibliotecas estáticas de terceros que definen los mismos símbolos?

Question

No puedo ser el único que se tope con esto.

Tengo una aplicación de C ++ que necesita vincularse con un tercero y otra biblioteca estática establecida en un SDK. El SDK, por alguna razón espantosamente frustrante, ha compilado un subconjunto de esa misma biblioteca de terceros en su propia biblioteca (renombrada), aunque los propios símbolos tienen el mismo nombre y no están encapsulados dentro de un espacio de nombres. Mi aplicación en sí depende de la misma biblioteca de terceros.

He considerado algunas opciones, pero tal vez me esté perdiendo algo y espero que una nueva mirada me ayude. Quizás esté cerca y alguien sepa el siguiente paso para uno de estos. Enumeraré lo que he intentado y las deficiencias de cada solución hasta el momento:

1. Enlace con ambos. Obtengo aproximadamente 2500 líneas de redefinición de símbolos / advertencias y errores de cambio de tamaño. Esto es cuando descubrí por primera vez que definían los mismos símbolos. Estoy tratando de volver a compilar OpenSSL con g ++ y soltarlo en un espacio de nombres en este momento ... ver edición abajo ...

2. Enlace con el SDK solamente. Obtengo símbolos indefinidos de los que depende mi propio código; esto es cuando descubrí que su recompilación de la biblioteca de terceros es un subconjunto, o al menos se configuró con un módulo deshabilitado.

3. Enlace con la biblioteca de terceros solamente. Tengo un par de símbolos no definidos reportados por el SDK, uno de ellos es en realidad un #define en un archivo de encabezado dentro de la biblioteca de terceros, por lo que todas las referencias en la biblioteca de terceros se resuelven a la definición, pero las referencias externas no lo hacen. Lo coloqué en el archivo c, que lo resuelve, sin embargo, todavía tengo dos funciones sin resolver que no puedo encontrar en ninguna parte. Esto es lo más cerca que he estado hasta ahora.

4. Pele los símbolos en conflicto de una lib y enlace en ambos. Hasta ahora esto no ha funcionado. Podría ser un problema de versión entre la biblioteca vinculada estáticamente en el SDK y las versiones que he intentado usar de la biblioteca de terceros, pero parece que algunas funciones se movieron entre símbolos, por lo que al eliminar un símbolo, elimino inadvertidamente una Función que necesito en otro lugar. No parece haber una asignación perfecta entre las funciones de los símbolos en el SDK y las funciones de los símbolos en la biblioteca de terceros. ¿Es plausible quitar funciones sin tener que ajustar manualmente las direcciones?

He estado examinando símbolos en libs con:

nm -C --defined-only lib<name>.a

Y extrayendo objetos enteros con:

ar -x lib<name>.a <objname>.o

Esperemos que esto también ayude a otros que han tenido que vincularse con librerías de terceros que entran en conflicto entre sí. Por razones específicas, la Opsec terceros es OpenSSL y el SDK es Opsec : libcpopenssl.a es la biblioteca ofensiva en Opsec.

** EDITAR - Una posible solución tardía para una entrada puede ser compilar OpenSSL con g ++ y colocar todo en un espacio de nombres, y luego vincular ambas librerías. Estoy intentando eso ahora ... más por venir ...

Answer 1

Si tienes curiosidad mórbida, se modificaron 249 archivos en la versión más reciente de OpenSSL para compilarlo. El problema más común con diferencia fue la abundancia de lanzamientos de punteros de estilo C, particularmente con vacío *. Ahora veo "reinterpret_cast" en mis sueños.

Sin embargo, esto no lo resolvió solo; aún debe colocarse en un espacio de nombres en su totalidad, lo que significa modificar de nuevo todos los archivos, así como mis propias referencias internas. Creo que voy a pasar esto por ahora.

Gracias por la ayuda a todos.

Answer 2

Una búsqueda en Google indica que SSL_get_peer_dh y DH_dup son realmente adiciones de libcpopenssl.a, y tampoco existen en mi copia de OpenSSL. Así que realmente tendrá que vincular esa biblioteca. Mezclar ambas bibliotecas (el Método 4 anterior) a nivel binario es poco probable que funcione. OpenSSL es muy exigente con su ABI (generalmente tienen archivos .so versionados hasta el número menor ) así que tendrías que ser muy afortunado de tener un .so que sea compatible con ABI con su archivo .a.

Mi sugerencia es una variación del Enfoque 4, pero a nivel de origen: tendrá un enlace en el libcpopenssl.a de Opsec, ya que es una versión modificada de OpenSSL que incluye símbolos adicionales (y posiblemente otras modificaciones), y asume las funciones adicionales que Los necesita desde los orígenes de OpenSSL y recompila esos objetos con libcpopenssl.a, para que puedan usar las funciones de la versión Opsec. Si solo está utilizando algunas funciones OpenSSL que no se exportan por libcpopenssl.a, esto es bastante factible.

Por supuesto, sigue siendo un enfoque engorroso, pero es una forma garantizada de obtener compatibilidad con los símbolos, dado que, por supuesto, el SDK de Opsec no realizó cambios semánticos en OpenSSL que interrumpirán las funciones OpenSSL adicionales que está incorporando a su proyecto.

(Soy nuevo en , así que no sé si esta sugerencia califica como una respuesta adecuada, pero no tengo puntos de reputación para publicar comentarios, de todos modos. Eliminaré esto si es inapropiado).