No se puede abrir el archivo de objeto compartido

Estoy intentando compilar uno de los proyectos que se encuentran aquí Adaptador de interfaz USB-I2C/SPI/GPIO.No se puede abrir el archivo de objeto compartido

He descargado el paquete i2c_bridge-0.0.1-rc2.tgz. Instalé libusb y eso pareció ir bien sin problemas. Voy al directorio i2c_bridge-0.0.1-rc2/ y hago. Eso compila. Me muevo a la carpeta i2c_bridge-0.0.1-rc2/i2c y hago. Compila y me da ./i2c. Sin embargo, cuando lo ejecuto, dice error while loading shared libraries: libi2cbrdg.so: cannot open shared object file: No such file or directory

El archivo MAKE en i2c_bridge-0.0.1-rc2/i2c tiene el directorio de la biblioteca como ../. El libi2cbrdg.so se encuentra en este directorio (i2c_bridge-0.0.1-rc2). También copié el archivo al /usr/local/lib. Un ls del directorio i2c_bridge-0.0.1-rc2/ es

i2c  i2cbrdg.d i2cbrdg.o libi2cbrdg.a Makefile tests 
i2cbrdg.c i2cbrdg.h INSTALL libi2cbrdg.so README u2c4all.sh

(Eso i2c es un directorio)

Si sudo ./i2c, todavía me da el problema.

Tuve que quitarme las opciones -Werror y -noWdecrepated (¿deletreo?) En todos los archivos MAKE para que compilen, pero eso no debería afectar esto ¿o sí?

¿Qué más es necesario para encontrar el archivo .so? Si alguien puede ayudarme a descubrir qué está mal, estaría muy agradecido. Si se necesita más información, puedo publicarlo.

Fuente

2011-11-07 Sterling

Tiene que distinguir entre encontrar lo que está en tiempo de compilación y en tiempo de ejecución. El indicador -L que das en tiempo de compilación no tiene nada que ver con la localización de la biblioteca en tiempo de ejecución. Esto se hace más bien a través de una serie de variables y algunas rutas incorporadas en la biblioteca.

El más caliente del arreglo para este problema es a menudo poniendo LD_LIBRARY_PATH al directorio con el archivo .so, por ejemplo:

$ LD_LIBRARY_PATH=.. ./i2c

Para una solución a largo plazo, es necesario que o bien tienen una mirada cercana a todo el sistema LD con rpath y runpath, o use libtool (que resuelve estos problemas para usted de forma portátil).

Copiar un archivo en/usr/local/lib a menudo es insuficiente porque almacena en caché las bibliotecas disponibles, por lo que necesita volver a ejecutar ldconfig (como raíz) después de copiar una biblioteca a/usr/local/lib.

Fuente

2011-11-07 16:54:46 thiton

¿LD_LIBRARY_PATH para todas mis bibliotecas? Entonces, si hago ese comando, ¿arruinará otras cosas hasta que lo cambie? ¿Cómo veo lo que está configurado ahora? – Sterling

Es una variable de entorno. Por lo tanto, puede verificarlo a través de "echo $ LD_LIBRARY_PATH" y, la forma en que se establece en la línea de comandos, es local para el proceso i2c y sus subprocesos. – thiton

No es mi pregunta, pero gracias a esto ayudó a resolver mi problema exacto – Rich

Si está compilando el código de la fuente que necesita la biblioteca, puede colocar la ruta en la que se encuentra la biblioteca en la variable de entorno LD_RUN_PATH antes del edificio, y el enlazador guardará esa ruta en el binario, de modo que se buscará automáticamente en el lugar correcto en tiempo de ejecución.

específico de Linux: Como alternativa, poner en la biblioteca /lib, /usr/lib, o algún otro camino que se hace referencia en sus /etc/ld.so.conf o sus fragmentos de configuración importados, y luego todo lo que necesita hacer es ejecutar /sbin/ldconfig para refrescar ld.so (enlazador dinámico) caché de bibliotecas.

Fuente

2012-02-03 08:45:17 rakslice

Aunque tenía '/ usr/local/lib' en'/etc/ld.so.conf.d/libc.conf', la ** biblioteca de enlaces dinámicos actualización de caché ** con 'sudo ldconfig' es lo que hizo por mí. –

Esto funciona para mi problema, la esperanza ayudará a cualquiera.

gcc test.c -Wl,-rpath /usr/local/lib -lfcgi -o test.fcg

Y -Wl,-rpath opción es el truco clave.

Fuente

2017-03-25 13:04:57 terwxqian

No se puede abrir el archivo de objeto compartido

Respuesta

Cuestiones relacionadas