Come sapere se una libreria ARM (.so) è compatibile con il Raspberry PI

Ho una libreria compilata (senza sorgente) per un driver di impronte digitali. Sono sicuro che sia una compilation ARM perché il comando file mylib.sodice:

Oggetto condiviso LSB a 32 bit ELF, ARM, versione 1 (SYSV), collegato dinamicamente, non rimosso

ma se voglio usarli in un programma C ++ ho sempre lo stesso errore:

errore durante il caricamento delle librerie condivise: mylib.so: impossibile aprire il file oggetto condiviso: nessun file o directory

questo errore come vedi non è molto esplicito, ovviamente ho usato il comando export sulla variabile LD_LIBRARY_PATH con il percorso di mylib.so.

quindi, come sapere se una libreria ARM (.so) è compatibile con il Raspberry PI?

-- Modificare --

ldd libsgfdu03.so:
not a dynamic executable

ldd libsgfdu04.so:
not a dynamic executable

ldd libsgfpamx.so:
not a dynamic executable

Nell'SDK, con .so, ho un programma C ++ di esempio per gestire il driver. Con due comandi per la compilazione in un makefile:

g++ -I./ -I../include -c main.cpp -> include un file chiamato "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

Tutti i percorsi sono buoni e nessun errore viene segnalato al momento della compilazione, ma dopo lddl'eseguibile finale 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)

- Modifica lo stesso driver 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)

Lo stesso exe (ma compilato per x86) non sembra richiedere altro. Sono totalmente perso ....

Prova a ldd foo.sovedere se c'è qualche risultato ragionevole. Se ricevi "avviso: non hai i permessi di esecuzione" è perché i file .so dovrebbero essere eseguibili ;).

Oltre a ciò, non so se esiste un modo semplice per controllare un .so per la compatibilità del sistema, ma dubito che otterresti l'errore "Non trovato" - Penso che davvero non riesca a trovarlo (penso anche lì è un errore "formato file non riconosciuto" più appropriato, e in effetti il ​​linker potrebbe non riconoscere un tale problema per cominciare). Quindi, per essere sicuri che siamo sulla stessa pagina con quello:

• Crea un collegamento simbolico nella stessa directory, ln -s foo.so libfoo.so.1- più tardi è quello che cercherò ld.

• Ora compila un programma di test g++ -L/directory/path test.cpp -lfoo.

Dice ancora "Nessun file o directory"?

WRT ldd output, se ottieni cose come questa:

libsgfpamx.so => not found

Indica che .so è collegato ad un altro .so che non può essere trovato nel percorso della libreria e quindi probabilmente non è installato. Se c'è motivo di credere che questa sia una libreria comune che dovrebbe essere disponibile - ad es. pthreads - è possibile cercare nel repository raspbian i pacchetti contenenti quel file:

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

Ora sappiamo che ci sono diversi pacchetti con un tale nome di file (libc6-dev e libc6: armhf). Ovviamente pthreads è già installato comunque. Tornando al tuo problema reale:

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

Sottolineando fortemente che siamo sfortunati WRT un pacchetto raspbian.

La ricerca online di "libsgfpamx.so" e "sgfpamx" non restituisce ... nulla. Quasi sicuramente si tratta di cose esoteriche o interne che sono state costruite insieme mylib.soe, se le hai già da qualche parte, sei fortunato, altrimenti dovrai informarti con le persone responsabili di "mylib.so".

Le librerie libsg sono librerie Secugen. Dovrai ottenere un SDK e ricostruirlo per la tua piattaforma.