У меня есть исполняемый файл, который нужно связать с libtest.so
динамически, поэтому я помещаю их в тот же каталог, а затем:
cd path_to_dir
./binary
Но получил вот это:
error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory
Как это может быть невозможно найти libtest.so
который уже находится в том же каталоге, что и сам исполняемый файл?
Хотя вы можете установить LD_LIBRARY_PATH, чтобы динамический компоновщик знал, где искать, есть и лучшие варианты. Вы можете разместить свою общую библиотеку в одном из стандартных мест, см. /etc/ld.so.conf
(в Linux) и /usr/bin/crle
(на Solaris) список этих мест
Вы можете пройти -R <path>
в компоновщик при создании вашего двоичного файла, который добавит <path>
в список каталогов, просканированных для вашей общей библиотеки. Вот пример. Сначала показываем проблему:
libtest.h:
void hello_world(void);
libtest.c:
#include <stdio.h>
void hello_world(void) {
printf("Hello world, I'm a library!\n");
}
Привет:
#include "libtest.h"
int main(int argc, char **argv) {
hello_world();
}
Makefile (необходимо использовать вкладки):
all: hello
hello: libtest.so.0
%.o: %.c
$(CC) $(CFLAGS) -fPIC -c -o $@ $<
libtest.so.0.0.1: libtest.o
$(CC) -shared -Wl,-soname,libtest.so.0 -o libtest.so.0.0.1 libtest.o
libtest.so.0: libtest.so.0.0.1
ln -s $< $@
clean:
rm -f hello libtest.o hello.o libtest.so.0.0.1 libtest.so.0
Запустим:
$ make
cc -fPIC -c -o libtest.o libtest.c
cc -shared -Wl,-soname,libtest.so.0 -o libtest.so.0.0.1 libtest.o
ln -s libtest.so.0.0.1 libtest.so.0
cc hello.c libtest.so.0 -o hello
$ ./hello
./hello: error while loading shared libraries: libtest.so.0: cannot open shared object file: No such file or directory
Как это исправить? Добавить -R <path>
к флагам компоновщика (здесь, установив LDFLAGS
).
$ make clean
(...)
$ make LDFLAGS="-Wl,-R -Wl,/home/maciej/src/tmp"
(...)
cc -Wl,-R -Wl,/home/maciej/src/tmp hello.c libtest.so.0 -o hello
$ ./hello
Hello world, I'm a library!
Посмотрев на двоичный файл, вы увидите, что ему нужны libtest.so.0
:
$ objdump -p hello | grep NEEDED
NEEDED libtest.so.0
NEEDED libc.so.6
Бинарный файл будет искать свои библиотеки, помимо стандартных мест, в указанном каталоге:
$ objdump -p hello | grep RPATH
RPATH /home/maciej/src/tmp
Если вы хотите, чтобы двоичный файл просматривался в текущем каталоге, вы можете установить для RPATH значение $ORIGIN
. Это немного сложно, потому что вам нужно убедиться, что знак доллара не интерпретируется make. Вот один из способов сделать это:
$ make CFLAGS="-fPIC" LDFLAGS="-Wl,-rpath '-Wl,\$\$ORIGIN'"
$ objdump -p hello | grep RPATH
RPATH $ORIGIN
$ ./hello
Hello world, I'm a library!
Загрузчик никогда не проверяет текущий каталог на наличие общих объектов, если он явно не направлен через $LD_LIBRARY_PATH
. Увидеть ld.so(8)
справочную страницу для более подробной информации.
Чтобы загрузить общие объекты из того же каталога, что и ваш исполняемый файл, просто выполните:
$ LD_LIBRARY_PATH=. ./binary
Примечание. Это не изменит переменную LD_LIBRARY_PATH вашей системы. Изменение касается только этого и только этого выполнения вашей программы.
Для всех, кто использует CMake для их сборки вы можете установить CMAKE_EXE_LINKER_FLAGS
на следующее:
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-rpath='$ORIGIN'")
Это будет правильно распространять флаги компоновщика для всех типов сборки (например, Debug, Release и т.д.), чтобы сначала искать файлы .so в текущем рабочем каталоге.
Для всех, кто все еще не может найти ответа, я сам нашел со следующим предложением:
Вы можете попробовать обновить ld.so.cache, используя: sudo ldconfig -v
Работал у меня.
Динамический компоновщик решит, где искать библиотеки. В случае Linux динамический компоновщик обычно GNU ld.so
(или альтернативу, которая обычно ведет себя идентично по соображениям совместимости.
На цитаты из Википедии:
Динамический компоновщик библиотеки GNU C выполняет поиск разделяемых библиотек в следующих местах:
- Пути (разделенные двоеточиями) в
DT_RPATH
атрибут динамического раздела двоичного файла, если он присутствует, иDT_RUNPATH
атрибут не существует.- Пути (разделенные двоеточиями) в переменной среды
LD_LIBRARY_PATH
, если исполняемый файл не являетсяsetuid
/setgid
двоичный, в этом случае он игнорируется.LD_LIBRARY_PATH
можно переопределить, вызвав динамический компоновщик с параметром --library-path (например, /lib/ld-linux.so.2 --library-path $ HOME / mylibs myprogram).- Пути (разделенные двоеточиями) в
DT_RUNPATH
атрибут динамического раздела двоичного файла, если он присутствует.- Поиск на основе файл кеша ldconfig (часто находится в
/etc/ld.so.cache
), который содержит скомпилированный список библиотек-кандидатов, ранее найденных в пути расширенной библиотеки (установленный/etc/ld.so.conf
). Если, однако, двоичный файл был связан с-z nodefaultlib
компоновщик, библиотеки в путях к библиотекам по умолчанию пропускаются.- В надежном пути по умолчанию
/lib
, а потом/usr/lib
. Если двоичный файл был связан с параметром компоновщика -z nodefaultlib, этот шаг пропускается.
Источник: https://en.wikipedia.org/wiki/Rpath