Espacio de tecnologia, software libre y sus derivados. Una horda de monos entrenados escriben de vez en cuando por aqui algunas noticias, opiniones e incluso alguna que otra cosa fuera del tema. Maqueros, favor de abstenerse que no somos lo suficientemente guapos.

Piano daemon

Tengo librerías no resueltas! ¿qué hago para resolverlas?

Después de leer la queja de un usuarios aun windowizado, y las respuestas un tanto agresivas. Creo que es necesario reconocer que debmos aceptarlo, es una pesadilla lidiar con “dependeincas y librerias”. Mejor informo de una técnica para solucionar este problema.

En linux se puede hacer todo, pero luego las herramientas “automágicas”, nos “nublan la visión y el fuente no es lo suficientemente explícito”. Así que si alguna vez han tenido broncas de librerías no resueltas, quizás ésto les pueda ayudar…

El uso de las librerías, te permite que, si tu programa necesita o quieres que maneje llaves de encriptación, simplemente “usas las funciones que te da el openssh”. Así no tienes que “programar” el openssh tú solito. Nada más lo usas y eso te da, reduccion de tiempo de desarrollo, una mayor calidad del software y menores costos. El problema radica en que el sistema “objetivo”, es decir nuestra maquina, no satisfaga esas dependencias, y entoces el baile y dolor de cabeza comienza. Así que aquí van un par de aspirinas para eso.

Debian, Red Hat, y sus derivados, no hacen la detección de las librerías, “automágicamente”. Linux provee un mecanismo con el cual uno puede saber que librerías requiere un programa, y si las tenemos o no.

Para hacer las cosas “optimas”, linux maneja un caché de librerías.
Este caché de librerías, es controlado por la aplicación “ldconfig”, y su archivo de configuración es ld.so.conf, el cual se encuentra en /etc.

Por lo tanto, tenemos:
Archivo de configuración de las librerías: /etc/ld.so.conf
Archivo que manipula el caché de las liberías: ldconfig

Con ésto, ya tenemos una primera idea de quien maneja la “disponibilidad” de las librerías. Ahora el problema es saber qué librerías usa un programa.

Simple, para eso está el comando ldd, el cual nos dice qué programa usa cual libreriá.
Ejemplo (andi pue’, ¡hasta con ejemplo!).
bash-2.05a$ which nslookup
/usr/bin/nslookup
bash-2.05a$ ldd /usr/bin/nslookup
libdns.so.5 => /usr/lib/libdns.so.5 (0×40021000)
libcrypto.so.0 => not found
libisc.so.4 => /usr/lib/libisc.so.4 (0×4010b000)
libnsl.so.1 => /lib/libnsl.so.1 (0×4013a000)
libc.so.6 => /lib/libc.so.6 (0×4014f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Primero uso el which para encontrar donde en mi sistema está la utilería “nslookup”.

Después uso ldd para saber las librerías que usa el programa de la cual sale mucha información.
La información esta estructurada en dos columnas.
La primera columna es la “librería” solicitada y la segunda columna es la ruta de la librería y el punto de entrada a la misma.

Si se fijan, tengo un problema de librerías. Me dice que:
libcrypto.so.0 => not found
No la encontró, así que tengo “dependencias no resueltas”.
¿Qué sigue? Buscar esa libreria en mi sistema.
find / -name “libcrypto.so.0″
lo cual me dice:
/usr/local/mylibs/libcrupto.so.0
Entonces sí tengo mi libreria, pero no me la “encuentra el sistema”, ¿entonces? ¿qué sucede? Simple, hay que “actualizar” mi sistema de caché:
Reviso mi /etc/ld.so.conf que contiene las rutas de búsqueda de las librerías, en mi caso particular:
bash-2.05a$ more /etc/ld.so.conf
/usr/local/lib
/usr/X11R6/lib
/usr/i386-slackware-linux/lib
/opt/kde/lib
/usr/lib/qt/lib
/usr/lib/qt/lib
Por lo tanto, edito mi /etc/ld.so.conf y agrego la ruta donde la librería se encuentra y mi /etc/ld.so.conf ahora dice:
bash-2.05a$ more /etc/ld.so.conf
/usr/local/lib
/usr/X11R6/lib
/usr/i386-slackware-linux/lib
/opt/kde/lib
/usr/lib/qt/lib
/usr/lib/qt/lib
/usr/local/mylibs

Ahora, actualizo mi “caché de librería” al ejecutar ldconfig
y vuelvo a probar el ldd sobre nslookup:
/usr/bin/nslookup
bash-2.05a$ ldd /usr/bin/nslookup
libdns.so.5 => /usr/lib/libdns.so.5 (0×40021000)
libcrypto.so.0 => /usr/local/mylibs/libcrypto.so.0 (0×400a1000)
libisc.so.4 => /usr/lib/libisc.so.4 (0×4010b000)
libnsl.so.1 => /lib/libnsl.so.1 (0×4013a000)
libc.so.6 => /lib/libc.so.6 (0×4014f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Listo. Dependendicas completadas.
Ahora, si el paso del “find” falla, pues eso significa que definitivamente no tengo esa libreria y hay que conseguirla. Google o Freshmeat, nos ayudan a esto.

El rpm y el apt-get, hacen prácticamente ésto. Así que si tú tienes un problema con un .tar.gz o algo así que te bajas “precompilado”, ya lo puedes resolver tú, que a diferencia de Windows, no puedes, a menos que utilices caras herramientas de desarrollo.

Ahora, cabe hacer mención, que no hay un procedimiento “perfecto”. Digamos que éste procedimiento es básico. Cuando éste falla se puede emplear strace o el gdb para “ver” que pasa.

Como recomendaciín, te suguero que uses Slackware o Gentoo, y manejes todo “a compilar”, dado que, para que compile algo, tienes que tener satisfechas todas las dependencias; asi garantizas que todo esté en donde debe de estar.

Espero que esta información le sirva a más de uno y sepan que hacer ante un:
bash-2.05a$ nslookup
nslookup: error while loading shared libraries: libcrypto.so.0: cannot open shared object file: No such file or directory

Alberto

February 5, 2008 @ 10:47 am

HOla tu aportacion esta genial, son cosas q difinitivamante ayudan, yo tengo un problema precisamente con las dependecias, tengo Centos 4.4 y Squid, pero para ver FTP externos necesito el FROX que es un proxy ftp, y segun tu procedimiento no le faltan dependencias, solo que el .log del install me marca que no encuentra el ac_nonexistent.h, y no lo encontre en ningun lado, incluido Google, ojala y pudieras ayudarme a solucionar este problema, de antemano gracias

RSS feed para comentarios en esta entrada · TrackBack URI

Comenta