Как узнать, совместима ли библиотека ARM (.so) с малиновым PI

У меня есть скомпилированная библиотека (без исходного кода) для драйвера отпечатков пальцев. Я уверен, что это компиляция ARM, потому что команда file mylib.soговорит:

ELF 32-битный общий объект LSB, ARM, версия 1 (SYSV), динамически связан, не разделен

но если я хочу использовать их в программе на C ++, у меня всегда одна и та же ошибка:

ошибка при загрузке общих библиотек: mylib.so: не удается открыть общий объектный файл: нет такого файла или каталога

эта ошибка, как вы видите, не очень явная, конечно, я использовал команду экспорта для переменной LD_LIBRARY_PATH с путем mylib.so.

Итак, как узнать, совместима ли библиотека ARM (.so) с малиновым PI?

-- Редактировать --

ldd libsgfdu03.so:
not a dynamic executable

ldd libsgfdu04.so:
not a dynamic executable

ldd libsgfpamx.so:
not a dynamic executable

В SDK у .soменя есть пример программы на C ++ для управления драйвером. С двумя командами для компиляции в одном make-файле:

g++ -I./ -I../include -c main.cpp -> включить один файл с именем "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

Все пути хороши, и об ошибке не сообщается во время компиляции, но после lddв конечном исполняемом файле ldd sgfplibtest_fdu03говорится:

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

Редактировать тот же драйвер с 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)

Тот же exe (но скомпилированный для x86), похоже, больше ничего не требует. Я полностью потерян ....

Попробуйте ldd foo.soи посмотрите, есть ли какой-либо разумный вывод. Если вы получаете «предупреждение: у вас нет разрешения на выполнение», это потому, что файлы .so должны быть исполняемыми ;).

Кроме того, я не знаю, есть ли простой способ проверить .so на совместимость системы, но я сомневаюсь, что вы получите ошибку «Не найден» - я думаю, что она действительно не может найти ее (я также думаю, что там является более подходящей ошибкой «формат файла не распознан», и на самом деле компоновщик может не распознать такую ​​проблему для начала). Так что просто чтобы убедиться, что мы находимся на одной странице с этим:

• Создайте символическую ссылку в том же каталоге, ln -s foo.so libfoo.so.1- позже будет искать ld.

• Теперь скомпилируйте тестовую программу g++ -L/directory/path test.cpp -lfoo.

Это все еще говорит "Нет такого файла или каталога"?

WRT ldd output, если вы получаете такие вещи:

libsgfpamx.so => not found

Это указывает, что .so связан с другим .so, который не может быть найден в пути к библиотеке и поэтому, вероятно, не установлен. Если есть основания полагать, что это общая библиотека, которая должна быть доступна, например. pthreads - вы можете искать в репозитории raspbian пакеты, содержащие этот файл:

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

Теперь мы знаем, что есть несколько пакетов с таким именем в них (libc6-dev и libc6: armhf). Конечно, pthreads уже установлен в любом случае. Возвращаясь к вашей актуальной проблеме:

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

Сильно подразумевая, что нам не повезло, WRT - распбиан.

Поиск в Интернете для "libsgfpamx.so" и "sgfpamx" не возвращает ... ничего. Почти наверняка это эзотерические или внутренние вещи, которые были построены вместе mylib.so, и если они у вас уже есть, вам повезло, в противном случае вам придется обратиться к людям, ответственным за «mylib.so».

Libsg libsg - это Secugen libs. Вам нужно будет получить SDK и восстановить его для вашей платформы.