Comment savoir si une bibliothèque ARM (.so) est compatible avec le Raspberry PI

J'ai une bibliothèque compilée (sans source) pour un pilote d'empreinte digitale. Je suis sûr que c'est une compilation ARM car la commande file mylib.sodit:

Objet partagé ELF 32 bits LSB, ARM, version 1 (SYSV), lié dynamiquement, non supprimé

mais si je veux les utiliser dans un programme C ++ j'ai toujours la même erreur:

erreur lors du chargement des bibliothèques partagées: mylib.so: impossible d'ouvrir le fichier d'objet partagé: aucun fichier ou répertoire de ce type

cette erreur comme vous le voyez n'est pas très explicite, bien sûr j'ai utilisé la commande d'exportation sur la variable LD_LIBRARY_PATH avec le chemin de mylib.so.

Alors, comment savoir si une bibliothèque ARM (.so) est compatible avec le Raspberry PI?

-- Éditer --

ldd libsgfdu03.so:
not a dynamic executable

ldd libsgfdu04.so:
not a dynamic executable

ldd libsgfpamx.so:
not a dynamic executable

Dans le SDK, avec le .so, j'ai un exemple de programme C ++ pour gérer le pilote. Avec deux commandes pour compiler dans un makefile:

g++ -I./ -I../include -c main.cpp -> inclure un fichier nommé "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

Tous les chemins sont bons et aucune erreur n'est signalée au moment de la compilation, mais après lddl'exécutable final ldd sgfplibtest_fdu03dit:

    /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)

- Modifier le même pilote avec 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)

Le même exe (mais compilé pour x86) ne semble plus exiger rien de plus. Je suis totalement perdu ...

Essayez de ldd foo.sovoir s'il existe une sortie raisonnable. Si vous obtenez "avertissement: vous n'avez pas l'autorisation d'exécution" c'est parce que les fichiers .so sont supposés être exécutables ;).

Au-delà de cela, je ne sais pas s'il existe un moyen simple de vérifier un .so pour la compatibilité du système, mais je doute que vous obteniez l'erreur "Not found" - je pense qu'il ne peut vraiment pas le trouver (je pense aussi est une erreur "format de fichier non reconnu" plus appropriée, et en fait que l'éditeur de liens peut ne pas reconnaître un tel problème pour commencer). Donc, juste pour être sûr que nous sommes sur la même longueur d'onde avec ça:

• Créez un lien symbolique dans le même répertoire, ln -s foo.so libfoo.so.1- le dernier est ce que ld recherchera.

• Compilez maintenant un programme de test g++ -L/directory/path test.cpp -lfoo.

Dit-il toujours "Aucun fichier ou répertoire"?

Sortie WRT ldd, si vous obtenez des trucs comme ceci:

libsgfpamx.so => not found

Il indique que le .so est lié à un autre .so introuvable dans le chemin d'accès à la bibliothèque et qu'il n'est donc probablement pas installé. S'il y a des raisons de croire que c'est une bibliothèque commune qui devrait être disponible - par exemple. pthreads - vous pouvez rechercher dans le dépôt raspbian les packages contenant ce fichier:

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

Nous savons maintenant qu'il y a plusieurs packages avec un tel nom de fichier (libc6-dev et libc6: armhf). Bien sûr, pthreads est déjà installé de toute façon. Revenons à votre problème réel:

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

Impliquant fortement que nous n'avons pas de chance WRT un paquet raspbian.

La recherche en ligne de "libsgfpamx.so" et "sgfpamx" ne renvoie ... rien. Ce sont certainement des choses ésotériques ou internes qui ont été construites avec mylib.so, et si vous les avez déjà quelque part, vous avez de la chance, sinon vous devrez vous renseigner auprès des personnes responsables de "mylib.so".

Les bibliothèques libsg sont des bibliothèques Secugen. Vous devrez obtenir un SDK et les reconstruire pour votre plate-forme.