Instalar una biblioteca localmente en el directorio de inicio, pero el programa no la reconoce

10

Estoy instalando un programa en un servidor como usuario no root. Específicamente, es tmux 1.5, pero en mi opinión, esto debería aplicarse ampliamente a todos los programas instalados localmente (menciono el nombre del programa en caso de que este problema no sea mi propio error).

El programa requiere que instale algunas bibliotecas dependientes (por ejemplo, libevent y ncurses). Entonces, los instalé localmente ya que no tengo acceso de root

cd $HOME/library/installation/folder
DIR=$HOME/local
./configure --prefix=$DIR 
#... make ... make install

Ahora, para instalar el programa, también tuve que incluir los paquetes de la biblioteca:

cd $HOME/program/installation/folder
./configure --prefix=$DIR CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib"
#... make ... make install

Ok, esto instala el programa sin problemas en $ HOME / local / bin, pero si ejecuto el ejecutable: $ HOME / local / bin / tmux, aparece el siguiente error:

tmux: error al cargar las bibliotecas compartidas: libevent-2.0.so.5: no se puede abrir el archivo de objeto compartido: No existe tal archivo o directorio

Me parece que el programa no puede encontrar las bibliotecas deseadas, pero el archivo libevent-2.0.so.5 sí existe en $ HOME / local / lib como se especifica en las opciones de configuración. Me pregunto cómo puedo hacer que el programa reconozca la biblioteca instalada para que se ejecute. Intenté poner enlaces simbólicos en $ HOME / lib, $ HOME / bin y $ HOME / local / bin, pero ninguno de estos funcionó. Cualquier idea y sugerencia sería muy apreciada.

linux installation terminal libraries home-directory scicalculator
fuente
Supongo -R $DIR/libque CFLAGSes mientras se construye tmux(y no libevent). Esto no me ayudó: hubo un error final de gcc que decía que no podía reconocer -R(también, intenté sin el espacio entre -Ry $DIR). ./configure --disable-shared Esto funcionó, actualizando el LD_LIBRARY_PATHtambién funcionó. Terminé haciendo de libeventnuevo con la --disable-sharedopción anterior .

Respuestas:

20

Intenta reconstruir libevent usando

./configure --disable-shared

Sospecho que esto solucionará su problema porque la biblioteca se vinculará al compilar el binario y no necesita buscarse en tiempo de ejecución.

Alternativamente, si necesita un libevent vinculado dinámicamente, puede agregar el directorio que contiene libevent-2.0.so.5 a su variable de entorno LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=${HOME}/local/lib/:${LD_LIBRARY_PATH}
drootang
fuente
Wow, muchas gracias por la rápida respuesta. Terminé usando LD_LIBRARY_PATH para solucionar el problema, ya que podría simplemente aplicar esta corrección a cualquier instalación futura de la biblioteca y siempre usar el directorio $ HOME / local. Agradezco la ayuda!
scicalculator
2

No tuve suerte con los demás, pero esto funcionó para mí, desde aquí :

sudo ln -s /usr/local/lib/libevent-2.0.so.5 /usr/lib64/libevent-2.0.so.5
beardc
fuente
2

He hecho una pregunta similar , curiosamente también sobre la construcción tmuxde todas las cosas (aunque todavía estoy seguro de que esto se refiere a casi cualquier situación en la que GNU configurey makese usan juntos.

Creo que un enfoque más limpio es utilizar el llamado "rpath", la ruta de búsqueda de la biblioteca incrustada en el binario. El -rpathinterruptor de al menos GNU linker ldespecifica la ruta.

La línea de comando de compilación se vería así:

PKG_CONFIG_PATH=/path/to/libevent/lib/pkg-config LDFLAGS=-Wl,-rpath,/path/to/libevent/lib ./configure ...

No es realmente primordial aquí, pero lo PKG_CONFIG_PATHanterior es simplemente la forma recomendada de hacer lo que la gente lograría enviar manualmente -L/path/to/libevent/lib -I/path/to/libevent/includeal ./configurescript. Cuando compila libevent, instala sus propios archivos de configuración para pkg-config(que es utilizado por ./configure). Debería usarlo, porque solo libevent definitivamente sabe qué interruptores deben usarse al construir contra él.

De todos modos, en algunas situaciones, -rpathes un enfoque más limpio para resolver el problema.

LD_LIBRARY_PATHSin embargo, las soluciones basadas en la tecnología le permiten hacer malabarismos con la biblioteca utilizada por su binario integrado en tiempo de ejecución, lo que a veces es deseable. Pero si solo desea construir contra una biblioteca en particular que haya colocado en un lugar dedicado en su carpeta de inicio en algún lugar, creo que las -rpathsoluciones basadas en el uso deben considerarse como una respuesta canónica.

Lo extraño es por qué tmuxlos propios scripts de compilación no infieren esta ruta desde la ruta de búsqueda de la biblioteca durante la construcción. Tal vez no necesitan y no deberían, no lo sé. ¿Es una coincidencia que nos haya sucedido a nosotros que construimos tmux?

amn
fuente