boost - una - impulsar bibliotecas construidas con rutas relativas

rutas relativas arcgis

Question

Creé boost 1.57.0 en QNX 6.5.0. No hay error de compilación Pero algunas bibliotecas están vinculadas a libboost_system.so especificando la ruta relativa. Guardé registros de compilación. Aquí está el paso de vinculación para boost_thread:

"QCC_gpp"   -o "bin.v2/libs/thread/build/qcc/release/threading-multi/libboost_thread.so.1.57.0"  -shared "bin.v2/libs/thread/build/qcc/release/threading-multi/pthread/thread.o" "bin.v2/libs/thread/build/qcc/release/threading-multi/pthread/once.o" "bin.v2/libs/thread/build/qcc/release/threading-multi/future.o" "bin.v2/libs/system/build/qcc/release/threading-multi/libboost_system.so.1.57.0"    -lm 

Entonces, cuando ejecuto ldd libboost_thread.so , no puede encontrar libboost_system. Creo que libboost_thread debe estar vinculado con la opción -lboost_system . Pero no sé cómo hacer esto.

Gracias.

Editar: No puedo construir ningún programa que vincule con boost_thread. Porque, boost_thread busca boost_system en la bin.v2/libs/system/build/qcc/release/threading-multi . Sin embargo, tanto boost_thread como boost_system están en una carpeta de búsqueda de la biblioteca. (definido con LD_LIBRARY_PATH )

Answer 1

Como escribió Nicklas Angare, el problema es que la entrada NEEDED contiene la ruta relativa en el tiempo de compilación, cuando debería contener el nombre del archivo .so.

Eso sucede porque las bibliotecas compartidas que se le dieron al enlazador no tienen un SONAME , y eso sucede porque el enlazador no recibió la opción -h .

De la documentación ld :

-h nombre
-soname = nombre
Al crear un objeto compartido ELF, configure el campo interno DT_SONAME con el nombre especificado. Cuando un ejecutable está vinculado con un objeto compartido que tiene un campo DT_SONAME, cuando se ejecuta el ejecutable, el vinculador dinámico intentará cargar el objeto compartido especificado por el campo DT_SONAME en lugar de usar el nombre de archivo dado al vinculador.

¿Por qué el enlazador no obtiene la opción -h para una compilación qcc ? Parece ser un error de Boost desde hace mucho tiempo pasado por alto (ver boleto de Boost.org , problema de Github )

La solución, como se sugiere en los enlaces anteriores, es eliminar $(HAVE_SONAME) de tools/build/v2/tools/qcc.jam

Answer 2

Creo que se supone que debes tomar las bibliotecas del área de preparación.

Por lo general, tengo algo similar a:

-L /home/.../boost/stage/lib/ -lboost_system

Por supuesto, reemplazando /home/.../boost con su directorio de impulso

Poco relacionado: con la configuración anterior, debe asegurarse de que las versiones correctas de las bibliotecas estén en la ruta de la biblioteca del cargador (LD_LIBRARY_PATH, ldconfig).

Si desea una compilación de desarrollo que pueda "ejecutar" en el sistema en el que lo creó, puede hornear la ruta de la biblioteca directamente en el binario de destino:

-Wl,-rpath -Wl,/home/.../boost/stage/lib/:/usr/lib/x86_64-linux-gnu

Answer 3

Si ejecuta objdump -p libboost_thread.so , encontrará que la entrada NEEDED para libboost_system.so contiene una ruta (relativa). De acuerdo con la especificación ELF, la entrada NEEDED debe contener solo el nombre de la biblioteca necesaria, por lo que parece haber un error en el enlazador o en QCC.

Porque si esto sucede, el sistema no podrá encontrar el archivo en tiempo de ejecución a menos que el directorio actual sea el mismo que cuando se realizó el enlace.

El trabajo más simple es vincular estáticamente a libboost_thread.a.

Otra -Wl,-L <path> -Wl,-l <name> que he usado es crear un contenedor alrededor de QCC que transforma la línea de comando para que las dependencias se den como -Wl,-L <path> -Wl,-l <name> lugar de <path>/lib<name>.so de <path>/lib<name>.so Esto también requiere un cambio en el sistema de compilación de Boost para que no añada el número de versión al final de los nombres de los archivos de la biblioteca.