#build #find #debian #shared-objects
#сборка #Найти #debian #общие объекты
Вопрос:
Я пытаюсь скомпилировать один из проектов, найденных здесь, адаптер интерфейса USB-I2C / SPI / GPIO.
Я скачал i2c_bridge-0.0.1-rc2.tgz пакет. Я установил libusb , и, похоже, все прошло хорошо, без проблем. Я захожу в i2c_bridge-0.0.1-rc2/ каталог и создаю. Это компилируется. Я перехожу в i2c_bridge-0.0.1-rc2/i2c папку и создаю. Он компилируется и выдает мне ./i2c . Однако, когда я запускаю его, он говорит error while loading shared libraries: libi2cbrdg.so: cannot open shared object file: No such file or directory
Makefile в i2c_bridge-0.0.1-rc2/i2c имеет каталог библиотеки как ../ . libi2cbrdg.so Находится в этом каталоге ( i2c_bridge-0.0.1-rc2 ). Я также скопировал файл в /usr/local/lib . ls Часть i2c_bridge-0.0.1-rc2/ каталога является
i2c i2cbrdg.d i2cbrdg.o libi2cbrdg.a Makefile tests
i2cbrdg.c i2cbrdg.h INSTALL libi2cbrdg.so README u2c4all.sh
(Это i2c каталог)
Если я sudo ./i2c , это все еще вызывает у меня проблему.
Мне пришлось убрать -Werror и -noWdecrepated (правописание?) параметры во всех make-файлах, позволяющие заставить их компилироваться, но это не должно повлиять на это, не так ли?
Что еще необходимо для поиска .so файла? Если кто-нибудь может помочь мне выяснить, что не так, я был бы очень благодарен. Если требуется дополнительная информация, я могу опубликовать ее.
Комментарии:
1.
cannot open shared object fileиногда решается путем выдачиsudo ldconfigдля обновления кэша общей библиотеки ранее скомпилированного и установленного пакета, чтобы подготовить его к компиляции последующего пакета
Ответ №1:
Вы должны различать поиск so во время компиляции и во время выполнения. -L Флаг, который вы даете во время компиляции, не имеет ничего общего с локализацией библиотеки во время выполнения. Это скорее делается с помощью ряда переменных и некоторых путей, встроенных в библиотеку.
Лучшим решением этой проблемы часто является установка LD_LIBRARY_PATH для каталога с .so файлом, например:
$ LD_LIBRARY_PATH=.. ./i2c
Для долгосрочного решения вам необходимо либо внимательно изучить всю систему LD с помощью rpath и runpath , либо использовать libtool (который решает эти проблемы для вашего переносимости).
Копирование файла в /usr/local/lib часто бывает недостаточным, поскольку ld доступные библиотеки кэшируются, поэтому вам необходимо повторно запустить ldconfig (от имени root) после копирования библиотеки в /usr/local/lib .
Комментарии:
1. Является ли LD_LIBRARY_PATH для всех моих библиотек? Значит, если я выполню эту команду, это испортит другие вещи, пока я не изменю ее обратно? Как мне увидеть, на что он установлен сейчас?
2. Это переменная среды. Таким образом, вы можете проверить это через «echo $ LD_LIBRARY_PATH» и, поскольку он задан в командной строке, является локальным для процесса i2c и его подпроцессов.
3. Не мой вопрос, но спасибо, что это помогло решить мою точную проблему
Ответ №2:
Если вы создаете код из исходного кода, которому требуется библиотека, вы можете указать путь, в котором находится библиотека, в переменной окружения LD_RUN_PATH перед сборкой, и компоновщик сохранит этот путь в двоичном файле, чтобы он автоматически искался в нужном месте во время выполнения.
Специфика Linux: Альтернативно, поместите библиотеку в /lib , /usr/lib или по какому-либо другому пути, указанному в вашем /etc/ld.so.conf или его импортированных фрагментах конфигурации, а затем все, что вам нужно сделать, это запустить /sbin/ldconfig для обновления ld.so кэш библиотек (динамического компоновщика).
Комментарии:
1. Несмотря на то, что у меня был
/usr/local/libin/etc/ld.so.conf.d/libc.conf, обновление кэша библиотеки динамических ссылок сsudo ldconfigпомощью — это то, что сделало это за меня.
Ответ №3:
Это работает для моей проблемы, надеюсь, кому-нибудь поможет.
gcc test.c -Wl,-rpath /usr/local/lib -lfcgi -o test.fcg
И -Wl,-rpath опция — это ключевой трюк.