Cómo saber si una biblioteca ARM (.so) es compatible con el raspberry PI

Tengo una biblioteca compilada (sin fuente) para un controlador de huellas digitales. Estoy seguro de que es una compilación ARM porque el comando file mylib.sodice:

Objeto compartido LSF de 32 bits ELF, ARM, versión 1 (SYSV), vinculado dinámicamente, no eliminado

pero si quiero usarlos en un programa C ++ siempre tengo el mismo error:

error al cargar bibliotecas compartidas: mylib.so: no se puede abrir el archivo de objeto compartido: No existe tal archivo o directorio

este error como ves no es muy explícito, por supuesto, he usado el comando de exportación en la variable LD_LIBRARY_PATH con la ruta de mylib.so.

Entonces, ¿cómo saber si una biblioteca ARM (.so) es compatible con el raspberry PI?

- Editar -

ldd libsgfdu03.so:
not a dynamic executable

ldd libsgfdu04.so:
not a dynamic executable

ldd libsgfpamx.so:
not a dynamic executable

En el SDK, con el .so, tengo un programa C ++ de muestra para administrar el controlador. Con dos comandos para compilar en un archivo MAKE:

g++ -I./ -I../include -c main.cpp -> incluye un archivo llamado "sgfplib.h"

g++ /usr/lib/arm-linux-gnueabihf/libusb.so -lpthread -lsgfpamx -lsgfdu03 -lsgfplib -o ../bin/arm12/sgfplibtest_fdu03 main.o -L/home/pi/sdk/lib/arm12

Todas las rutas son buenas y no se informa ningún error en el momento de la compilación, pero luego ldden el ejecutable final ldd sgfplibtest_fdu03dice:

    /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so (0xb6f76000)
    libusb-0.1.so.4 => /lib/arm-linux-gnueabihf/libusb-0.1.so.4 (0xb6f5a000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6f3b000)
    libsgfpamx.so => not found
    libsgfdu04.so => not found
    libsgfplib.so => not found
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6e6e000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6dfd000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6dd5000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6ca6000)
    /lib/ld-linux-armhf.so.3 (0xb6f83000)

- Edite el mismo controlador con debian x86 -

dpkg -S libsgfpamx.so 

dpkg-query: no path found matching pattern *libsgfpamx.so*

ldd sgfplibtest_fdu03 :

    linux-gate.so.1 =>  (0xb76eb000)
    libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb76d1000)
    libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb76b8000)
    libsgfpamx.so => /usr/local/lib/libsgfpamx.so (0xb769d000)
    libsgfdu03.so => /usr/local/lib/libsgfdu03.so (0xb7632000)
    libsgfplib.so => /usr/local/lib/libsgfplib.so (0xb7623000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7536000)
    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7510000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb74f1000)
    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb73aa000)
    /lib/ld-linux.so.2 (0xb76ec000)

El mismo exe (pero compilado para x86) no parece requerir nada más. Estoy totalmente perdido ...

Pruebe ldd foo.soy vea si hay algún resultado razonable. Si recibe "advertencia: no tiene permiso de ejecución" es porque se supone que los archivos .so son ejecutables ;).

Más allá de eso, no sé si hay una manera simple de verificar un .so para la compatibilidad del sistema, pero dudo que obtenga el error "No encontrado". Creo que realmente no puede encontrarlo (también creo que hay es un error más apropiado de "formato de archivo no reconocido", y de hecho es posible que el vinculador no reconozca tal problema para empezar). Así que para asegurarnos de que estamos en la misma página con eso:

• Cree un enlace simbólico en el mismo directorio, ln -s foo.so libfoo.so.1lo que más tarde es lo que buscará ld.

• Ahora compile un programa de prueba g++ -L/directory/path test.cpp -lfoo.

¿Sigue diciendo "No existe tal archivo o directorio"?

WRT ldd output, si obtienes cosas como esta:

libsgfpamx.so => not found

Indica que .so está vinculado a otro .so que no se puede encontrar en la ruta de la biblioteca y, por lo tanto, es probable que no esté instalado. Si hay razones para creer que esta es una biblioteca común que debería estar disponible, por ejemplo. pthreads: puede buscar en el repositorio raspbian paquetes que contengan ese archivo:

> dpkg -S libpthread.so
libc6-dev:armhf: /usr/lib/arm-linux-gnueabihf/libpthread.so
libc6:armhf: /lib/arm-linux-gnueabihf/libpthread.so.0

Ahora sabemos que hay varios paquetes con ese nombre de archivo (libc6-dev y libc6: armhf). Por supuesto, pthreads ya está instalado de todos modos. Volviendo a su problema real:

dpkg -S libsgfpamx.so
dpkg-query: no path found matching pattern *libsgfpamx.so*

Esto implica que no tenemos suerte. WRT es un paquete raspbian.

Buscando en línea "libsgfpamx.so" y "sgfpamx" devuelve ... nada. Es casi seguro que se trata de elementos esotéricos o internos que se construyeron junto con ellos mylib.so, y si los tiene en algún lugar ya está de enhorabuena, de lo contrario, deberá consultar con las personas responsables de "mylib.so".

Las libsg libsg son Secugen libs. Tendrá que obtener un SDK y reconstruirlos para su plataforma.