¿Cómo me deshago de LD_LIBRARY_PATH en tiempo de ejecución?

Estoy construyendo una aplicación C++ que usa la biblioteca IPP de Intel. Esta biblioteca está instalada de manera predeterminada en/opt y requiere que establezca LD_LIBRARY_PATH tanto para compilar como para ejecutar su software (si elige la biblioteca compartida, lo cual hice). Ya modifiqué mi configure.ac/Makefile.am para no tener que establecer esa variable al compilar, pero aún no puedo encontrar la biblioteca compartida en tiempo de ejecución; ¿Cómo puedo hacer eso?¿Cómo me deshago de LD_LIBRARY_PATH en tiempo de ejecución?

Estoy compilando con la bandera -Wl, -R/path/to/libdir usando g++

Actualización 1: En realidad mi programa binario tiene algunas bibliotecas IPP vinculados correctamente, pero sólo uno no es:

$ ldd myprogram 
linux-vdso.so.1 => (0x00007fffa93ff000) 
libippacem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippacem64t.so.6.0 (0x00007f22c2fa3000) 
libippsem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippsem64t.so.6.0 (0x00007f22c2d20000) 
libippcoreem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippcoreem64t.so.6.0 (0x00007f22c2c14000) 
[...] 
libiomp5.so => not found 
libiomp5.so => not found 
libiomp5.so => not found

Por supuesto la biblioteca está allí:

$ locate libiomp5.so 
/opt/intel/ipp/6.0.2.076/em64t/sharedlib/libiomp5.so

Fuente

2010-03-20 Kjir

Podría necesitar cambiar la pregunta a otra cosa, pero necesito sugerencias, estoy corto de ideas – Kjir

Hm, me pregunto si es una coincidencia que a esa también le falta la extensión del número de versión - tal vez IPP simplemente no es instalarse ¿verdad? – Cascabel

Me pregunto si la biblioteca omitida no está referenciada en su programa, sino en las bibliotecas de sus referencias. –

Según lo sugerido por Richard Pennington, la biblioteca que falta no es utilizada directamente por mi aplicación, pero es utilizada por las bibliotecas compartidas que uso. Como no puedo recompilar IPP, la solución a mi problema es agregar -liomp5 al compilar, usando la opción -R para el enlazador. ¡Esto realmente agrega el rpath para libiomp5.so solucionando el problema!

Fuente

2010-03-22 19:16:54 Kjir

-1

bash:

export LD_LIBRARY_PATH=/path/to/lib

tcsh:

setenv LD_LIBRARY_PATH /path/to/lib

Fuente

2010-03-20 18:54:30

La pregunta es cómo * no * tener que establecer LD_LIBRARY_PATH, no cómo configurarlo. Esta es una pregunta muy razonable, ya que establecer LD_LIBRARY_PATH puede ser bastante malo. – Cascabel

Por /path/to/lib qué se refiere ruta de acceso al directorio que contiene la biblioteca, o la ruta de acceso al archivo real?

La opción -R dado un argumento de directorio se trata como -rpath por ld, que es la opción que realmente desea aquí. Agrega el directorio dado a la ruta de búsqueda de la biblioteca de tiempo de ejecución. Eso debería funcionar, siempre que le proporcione el directorio y no el nombre del archivo. Estoy bastante seguro de eso, después de haber hecho yo mismo, y porque es uno de los consejos dados por libtool:

librerías se han instalado en:

/ruta/a/biblioteca de directorio

Si alguna vez desea vincularse con las bibliotecas instaladas en un directorio determinado, LIBDIR, debe utilizar libtool y especificar la ruta de acceso completa de la biblioteca, o utilizar el indicador `-LLIBDIR ' durante la vinculación y hacer al menos uno de los siguientes:

añadir LIBDIR a la LD_LIBRARY_PATH ` 'variable de entorno durante la ejecución

añadir LIBDIR a la` LD_RUN_PATH' variable de entorno durante la vinculación

utiliza el `-Wl, -rpath -Wl, LIBDIR' bandera enlazador

haga que su administrador del sistema agregue LIBDIR a `/etc/ld.so.conf'

(I pega este aquí, ya que es concebible una de las otras opciones podría ser más deseable - por ejemplo LD_RUN_PATH puede ahorrar modificación makefile)

Fuente

2010-03-20 18:56:26 Cascabel

Modifiqué la pregunta para especificar mejor que efectivamente apunte a un directorio. Agregar esa opción a la etapa de enlace resolvió el problema en el momento de la compilación, pero el tiempo de ejecución aún no funciona. Por supuesto hice 'make clean && make' para asegurarme de haber actualizado los binarios ... – Kjir

Podrías probar con la ruta' LD_RUN_PATH', por si acaso? – Cascabel

Puede comprobar si la ruta a la biblioteca es siendo recogido de su indicador -R ejecutando el comando ldd o el comando readelf en su binario. La variable de entorno LD_LIBRARY_PATH es una anulación, por lo que no debería ser necesaria normalmente.

Fuente

2010-03-20 19:01:20 abc

-1

Intente configurar su ldconfig a través de ld.so.conf para que busque su directorio /opt/... de forma predeterminada.

Fuente

2010-03-20 19:46:25 jpalecek

Esa no es una opción viable, sería como establecer LD_LIBRARY_PATH, pero posiblemente menos portátil. También requeriría una tarea administrativa, que no resuelve el problema principal, que es hacer lo menos doloroso posible para que el siguiente usuario/desarrollador ejecute el software. – Kjir

Debe usar la opción -R si es posible.

De lo contrario, cambie el nombre de su ejecutable y cree una secuencia de comandos de inicio que ejecute su ejecutable, y allí configure LD_LIBRARY_PATH solo para ese ámbito.

Dependiendo de la plataforma, puede modificar ld.so.conf a través de /etc/ld.so.conf.d (Redhat/Fedora viene a la mente) lo que hace que la implementación de cambios en ld.so sea "más fácil" desde un escenario de implementación .

Fuente

2010-03-20 20:02:57 Joe

¿Miraste la información ya publicada?El OP * es * usando la opción '-R'; el problema es que no está funcionando como se esperaba. Y modificar ld.so.conf es como establecer LD_LIBRARY_PATH, pero lo que es peor, se aplica a todo, no solo a este programa, y no es más fácil implementarlo de una manera que siempre requiere de root. – Cascabel

Además, aunque un script de envoltura funcionaría, no solo es poco elegante, pero en algunos casos poco probables pero posibles, podría ser problemático: si el programa en cuestión lanza otros programas, heredarán esa variable de entorno, y usted estará nuevamente abierto a los problemas habituales con LD_LIBRARY_PATH de nuevo. – Cascabel

No digo que sean buenas soluciones, pero si el usuario final está instalando componentes en tiempo de ejecución que son dependencias y que no se agregan explícitamente a los métodos de búsqueda del sistema, entonces sus opciones son extremadamente limitadas. Básicamente, hay solo dos formas de encontrar libs dinámicas fuera de los valores predeterminados: actualiza ld.so o usa LD_LIBRARY_PATH (o LD_RUN_PATH) de alguna forma. – Joe

Además de todas las sugerencias útiles publicadas aquí ... no está tratando de usar una biblioteca específica de 64 bits en un sistema de 32 bits (o viceversa, dependiendo de otras condiciones), ¿verdad?

Fuente

2010-03-20 21:01:07 lorenzog

Si fuera así, no funcionaría incluso configurando LD_LIBRARY_PATH ... – Kjir

¿Cómo me deshago de LD_LIBRARY_PATH en tiempo de ejecución?

Respuesta

Cuestiones relacionadas