Почему ld need-rpath-link при связывании исполняемого файла с so, который нуждается в другом so?

почему это, что ld должен быть в состоянии найти liba.so при связывании test? Потому что мне не кажется, что ld делает что-то еще, кроме подтверждения liba.so's существование. Например, бег readelf --dynamic ./test только списки libb.so по мере необходимости, поэтому я думаю, что динамический компоновщик должен обнаружить libb.so -> liba.so зависимость сама по себе, и сделать это собственный поиск liba.so.

Ну, если я правильно понимаю процесс связывания,ld на самом деле не нужно найти еще libb.so. Он может просто игнорировать все неразрешенные ссылки в test надеясь, что динамический компоновщик разрешит их при загрузке libb.so во время выполнения. Но если ... --66-->ld таким образом, многие ошибки "неопределенной ссылки" не будут обнаружены во время ссылки, вместо этого они будут найдены при попытке загрузить test в runtime. Так что ld просто делает дополнительную проверку, что все символы не найдены в test себя можно действительно найти в shared библиотеки, которые test зависит от. Так что если test программа имеет ошибку" неопределенная ссылка " (некоторая переменная или функция не найдена в и ни libb.so), это становится очевидным во время ссылки, а не только во время выполнения. Таким образом, такое поведение является лишь дополнительной проверкой здравомыслия.

но ld идет еще дальше. При ссылке test, ld также проверяет, что все неразрешенные ссылки в libb.so находятся в общих библиотеках, которые libb.so зависит (в нашем случае libb.so зависит от liba.so, поэтому он требует liba.so быть расположенным на времени соединения). Ну, вообще-то ld уже сделал эту проверку, когда он связывал libb.so. Почему он делает эту проверку во второй раз... Может быть, разработчики ld нашел эту двойную проверку полезной для обнаружения сломанных зависимостей при попытке связать вашу программу с устаревшей библиотекой, которая может быть загружена во времена, когда она была связана, но теперь она не может загружаться, потому что библиотеки, от которых он зависит, обновляются (например,liba.so позже был переработан, и часть функции была удалена из него).

UPD

просто сделал несколько экспериментов. Кажется, мое предположение "на самом деле ld уже сделал эту проверку, когда он связывал libb.so" - это неправильно.

допустим liba.c имеет следующее содержание:

int liba_func(int i)
{
    return i + 1;
}

и libb.c имеет далее:

int liba_func(int i);
int liba_nonexistent_func(int i);

int libb_func(int i)
{
    return liba_func(i + 1) + liba_nonexistent_func(i + 2);
}

и test.c

#include <stdio.h>

int libb_func(int i);

int main(int argc, char *argv[])
{
    fprintf(stdout, "%d\n", libb_func(argc));
    return 0;
}

при связывании libb.so:

gcc -o libb.so -fPIC -shared libb.c liba.so

linker не генерирует никаких сообщений об ошибках, которые liba_nonexistent_func невозможно решить, вместо этого он просто молча генерирует сломанную общую библиотеку libb.so. Поведение такое же, как и при создании статической библиотеки (libb.a) С ar который также не разрешает символы сгенерированной библиотеки.

но когда вы пытаетесь связать test:

gcc -o test -Wl,-rpath-link=./ test.c libb.so

вы получили ошибку:

libb.so: undefined reference to `liba_nonexistent_func'
collect2: ld returned 1 exit status

обнаружение такой ошибки было бы невозможно, если ld не сканировал рекурсивно все общие библиотеки. Поэтому кажется, что ответ на вопрос такой же, как я сказал выше: ld должен - rpath-link чтобы убедиться, что связанный исполняемый файл может быть загружен позже динамической загрузкой. Просто вменяемость проверять.

UPD2

имеет смысл проверить наличие неразрешенных ссылок как можно раньше (при связывании libb.so), но ld по каким-то причинам не делает этого. Вероятно, это позволяет создавать циклические зависимости для общих библиотек.

liba.c может иметь следующую реализацию:

int libb_func(int i);

int liba_func(int i)
{
    int (*func_ptr)(int) = libb_func;
    return i + (int)func_ptr;
}

так liba.so использует libb.so и libb.so использует liba.so (лучше никогда этого не делать). Этот успешно компилирует и работает:

$ gcc -o liba.so -fPIC -shared liba.c
$ gcc -o libb.so -fPIC -shared libb.c liba.so
$ gcc -o test test.c -Wl,-rpath=./ libb.so
$ ./test
-1217026998

хотя readelf выступает говорит, что liba.so не нужно libb.so:

$ readelf -d liba.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
$ readelf -d libb.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [liba.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

если ld проверено на наличие неразрешенных символов во время связывания общей библиотеки, связывание liba.so было бы невозможно.

обратите внимание, что я использовал - rpath ключ вместо - rpath-link. Разница в том, что - rpath-link используется во время связывания только для проверки того, что все символы в конечном исполняемом файле могут быть разрешены, тогда как - rpath фактически вставляет путь, который вы указываете в качестве параметра в ELF:

$ readelf -d test | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [./]

так что теперь можно запустить test если общие библиотеки (liba.so и libb.so) находятся в вашем текущем рабочем каталоге (./). Если вы просто использовали - rpath-link такой записи не будет в test ELF, и вам нужно будет добавить путь к общему библиотеки в или LD_LIBRARY_PATH переменные среды.

UPD3

на самом деле можно проверить наличие неразрешенных символов во время связывания общей библиотеки, --no-undefined опция должна использоваться для этого:

$ gcc -Wl,--no-undefined -o libb.so -fPIC -shared libb.c liba.so
/tmp/cc1D6uiS.o: In function `libb_func':
libb.c:(.text+0x2d): undefined reference to `liba_nonexistent_func'
collect2: ld returned 1 exit status

также я нашел хорошую статью, которая разъясняет многие аспекты связывание общих библиотек, которые зависят от других библиотек: лучшее понимание вторичных зависимостей Linux, решающих с помощью примеры.