El programa es parte de la suite de pruebas Xenomai, compilada de manera cruzada desde PC con Linux a la cadena de herramientas Linux + Xenomai ARM.
# echo $LD_LIBRARY_PATH
/lib
# ls /lib
ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so
ld-linux.so.2 libdl.so.2 libpthread.so.0
libc-2.3.3.so libgcc_s.so libpthread_rt.so
libc.so.6 libgcc_s.so.1 libstdc++.so.6
libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9
libcrypt.so.1 libm.so.6
# ./clocktest
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory
Editar: OK No noté que el .1 al final era parte del nombre del archivo. ¿Qué significa eso, de todos modos?
linux
shared-libraries
file-not-found
xenomai
zaratustra
fuente
fuente
Respuestas:
Actualización
Si bien lo que escribo a continuación es cierto como una respuesta general sobre las bibliotecas compartidas, creo que la causa más frecuente de este tipo de mensajes es porque ha instalado un paquete, pero no ha instalado la versión "-dev" de ese paquete.
Bueno, no está mintiendo, no hay nada
libpthread_rt.so.1
en esa lista. Probablemente necesite reconfigurarlo y reconstruirlo de modo que dependa de la biblioteca que tenga, o instalar lo que sea que proporcionelibpthread_rt.so.1
.En general, los números después de .so son números de versión, y a menudo encontrará que son enlaces simbólicos entre sí, por lo que si tiene la versión 1.1 de libfoo.so, tendrá un archivo real libfoo.so.1.0, y enlaces simbólicos foo.so y foo.so.1 apuntando a libfoo.so.1.0. Y si instala la versión 1.1 sin eliminar la otra, tendrá un libfoo.so.1.1, y libfoo.so.1 y libfoo.so ahora apuntarán a la nueva, pero cualquier código que requiera esa versión exacta puede use el archivo libfoo.so.1.0. El código que solo se basa en la API de la versión 1, pero no le importa si es 1.0 o 1.1 especificará libfoo.so.1. Como orip señaló en los comentarios, esto se explica bien en http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .
En su caso, usted puede salirse con enlaces simbólicos
libpthread_rt.so.1
alibpthread_rt.so
. Sin embargo, no hay garantías de que no romperá su código y se comerá sus cenas de TV.fuente
Tu biblioteca es una biblioteca dinámica. Debe decirle al sistema operativo dónde puede ubicarlo en tiempo de ejecución.
Para hacerlo, tendremos que seguir estos sencillos pasos:
(1) Encuentre dónde se ubica la biblioteca si no la conoce.
(2) Verifique la existencia de la variable de entorno de ruta de biblioteca dinámica (
LD_LIBRARY_PATH
)Si no hay nada que mostrar, agregue un valor de ruta predeterminado (o no si lo desea)
(3) Agregamos la ruta del deseo, la exportamos y probamos la aplicación.
Tenga en cuenta que la ruta debe ser el directorio donde
path.so.something
está. Entonces, sipath.so.something
está adentro/my_library/path.so.something
, debería ser:fuente: http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html
fuente
find
solo:find / -name the_name_of_the_file.so
LD_LIBRARY_PATH
debería apuntar al directorio que contienepath.so.something
, no apath.so.something
sí mismo.Aquí hay algunas soluciones que puede probar:
ldconfig
Como señaló AbiusX: si acaba de instalar la biblioteca, es posible que simplemente necesite ejecutar ldconfig .
Por lo general, su administrador de paquetes se encargará de esto cuando instale una nueva biblioteca, pero no siempre, y no le hará daño ejecutar ldconfig incluso si ese no es su problema.
Paquete de desarrollo o versión incorrecta
Si eso no funciona, también verificaría la sugerencia de Paul y buscaría una versión "-dev" de la biblioteca. Muchas bibliotecas se dividen en paquetes dev y no dev. Puede usar este comando para buscarlo:
Esto también puede ayudar si simplemente tiene instalada la versión incorrecta de la biblioteca. Algunas bibliotecas se publican en diferentes versiones simultáneamente, por ejemplo, Python.
Ubicación de la biblioteca
Si está seguro de que está instalado el paquete correcto y ldconfig no lo encontró, es posible que esté en un directorio no estándar. Por defecto, ldconfig se ve en
/lib
,/usr/lib
y aparece en los directorios/etc/ld.so.conf
y$LD_LIBRARY_PATH
. Si su biblioteca está en otro lugar, puede agregar el directorio en su propia línea/etc/ld.so.conf
, agregar la ruta de$LD_LIBRARY_PATH
la biblioteca o moverla/usr/lib
. Entonces correldconfig
.Para averiguar dónde está la biblioteca, intente esto:
(Reemplace
libraryname
con el nombre de su biblioteca)Si sigue la
$LD_LIBRARY_PATH
ruta, querrá incluirla en su~/.bashrc
archivo para que se ejecute cada vez que inicie sesión:fuente
.conf
mis propios archivos con las rutas lib no estándar que necesito/etc/ld.so.conf.d
(señalado por/etc/ld.so.conf
) hizo el truco.Tuve un error similar, pude resolverlo dando,
Espero que esto ayude.
fuente
Debe asegurarse de especificar la ruta de la biblioteca durante la vinculación cuando compila su archivo .c:
La parte -Wl, -R le dice al binario resultante que también busque la biblioteca en / usr / local / lib en tiempo de ejecución antes de intentar usar la que está en / usr / lib /
Espero que te ayude.
fuente
-Wl,-rpath DIR
.Intente agregar
LD_LIBRARY_PATH
, que indica rutas de búsqueda, a su~/.bashrc
archivo¡Funciona!
fuente
La página de referencia de linux.org explica la mecánica, pero no explica ninguna de las motivaciones :-(
Para eso, consulte Sun Linker y la Guía de Bibliotecas
Además, tenga en cuenta que el "control de versiones externo" es en gran parte obsoleto en Linux, porque el control de versiones de símbolos (una extensión GNU) le permite tener múltiples versiones incompatibles de la misma función para estar presentes en una sola biblioteca. Esta extensión permitió que glibc tuviera la misma versión externa:
libc.so.6
durante los últimos 10 años.fuente
agregue estas líneas al final
fuente
Tuve un error similar y no se solucionó al dar LD_LIBRARY_PATH en ~ / .bashrc. Lo que resolvió mi problema es agregando el archivo .conf y cargándolo. Ir a la terminal y estar en su.
Agregue la ruta de su biblioteca en este archivo y guárdela (por ejemplo: / usr / local / lib). Debe ejecutar el siguiente comando para activar la ruta:
Verifique su nueva ruta de biblioteca:
Si esto muestra los archivos de su biblioteca, entonces está listo para comenzar.
fuente
Otra posible solución dependiendo de su situación.
Si sabe que libpthread_rt.so.1 es lo mismo que libpthread_rt.so, puede crear un enlace simbólico de la siguiente manera:
Entonces
ls -l /lib
ahora debería mostrar el enlace simbólico y a qué apunta.fuente
Tuve este error al ejecutar mi aplicación con Eclipse CDT en Linux x86.
Para arreglar esto:
Establecer el camino
fuente
Todo lo que tenía que hacer era correr:
Estaba en la carpeta ubicada en
/usr/lib/x86_64-linux-gnu
y funcionó perfectamente.fuente
Si está ejecutando su aplicación en Microsoft Windows, la ruta a las bibliotecas dinámicas (.dll) debe definirse en la variable de entorno PATH.
Si está ejecutando su aplicación en UNIX, la ruta a sus bibliotecas dinámicas (.so) debe definirse en la variable de entorno LD_LIBRARY_PATH.
fuente
intente instalar sudo lib32z1
fuente
El error ocurre ya que el sistema no puede referirse al archivo de biblioteca mencionado. Siga los siguientes pasos:
locate libpthread_rt.so.1
mostrará la ruta de todos los archivos con ese nombre. Supongamos que hay un camino/home/user/loc
.cd home/USERNAME
. Reemplace USERNAME con el nombre del usuario activo actual con el que desea ejecutar el archivo.vi .bash_profile
y al final delLD_LIBRARY_PATH
parámetro, justo antes.
, agregue la línea/lib://home/usr/loc:.
. Guarda el archivo.fuente
Recibí este error y creo que es la misma razón que la tuya.
Prueba esto. Corregir permisos en archivos:
"Sudo su" para obtener permisos en su sistema de archivos.
fuente
Recibí este error y creo que es la misma razón que la tuya.
Prueba esto. Corregir permisos en archivos:
fuente
problema similar encontrado aquí: https://bugzilla.redhat.com/show_bug.cgi?id=1456202 He probado la solución mencionada y realmente funciona.
Las soluciones en las preguntas anteriores pueden funcionar. Pero creo que esta es una manera fácil de solucionarlo. Intente reinstalar el paquete
libwbclient
en fedora:fuente
Yo uso Ubuntu 18.04
Instalar el paquete "-dev" correspondiente funcionó para mí,
Recibí el siguiente error hasta que instalé el paquete anterior,
fuente