¿Por qué ld necesita-rpath-link cuando enlaza un ejecutable contra un so que necesita otro so?

¿Por qué es que ld DEBE ser capaz de localizar liba.so al enlazar test? Porque a mí no me parece que ld esté haciendo mucho más que confirmar la existencia de liba.so. Por ejemplo, ejecutar readelf --dynamic ./test solo lista libb.so según sea necesario, así que supongo que el enlazador dinámico debe descubrir la dependencia libb.so -> liba.so por sí mismo, y hacer su propia búsqueda de liba.so.

Bueno, si entiendo el proceso de enlace correctamente, ld en realidad no necesita localizar incluso libb.so. Podría simplemente ignore todas las referencias no resueltas en test esperando que dynamic linker las resuelva al cargar libb.so en tiempo de ejecución. Pero si ld estuviera haciendo esto, muchos errores de "referencia indefinida" no se detectarían en el momento del enlace, sino que se encontrarían al intentar cargar test en tiempo de ejecución. Así que ld simplemente hace una comprobación adicional de que todos los símbolos que no se encuentran en test pueden encontrarse realmente en bibliotecas compartidas de las que depende test. Así que si test programa tiene " indefinido reference " error (alguna variable o función que no se encuentra en test y tampoco en libb.so), esto se hace obvio en tiempo de enlace, no solo en tiempo de ejecución. Por lo tanto, tal comportamiento es solo una comprobación adicional de la cordura.

Pero ld va aún más lejos. Cuando se enlaza test, ld también comprueba que todas las referencias no resueltas en libb.so se encuentran en las bibliotecas compartidas de las que depende libb.so (en nuestro caso libb.so depende de liba.so, por lo que requiere que liba.so se encuentre en el momento del enlace). Bueno, en realidad ld ya ha hecho esta comprobación, cuando estaba enlazando libb.so. ¿Por qué hace esta comprobación por segunda vez... Tal vez los desarrolladores de ld encontraron esta doble comprobación útil para detectar dependencias rotas cuando intenta vincular su programa con una biblioteca obsoleta que podría cargarse en los momentos en que se vinculó, pero ahora no se puede cargar porque las bibliotecas de las que depende se actualizan (por ejemplo, liba.so se volvió a trabajar más tarde y de ella).

UPD

Solo hice algunos experimentos. Parece que mi suposición " en realidad ld ya ha hecho esta comprobación, cuando estaba enlazando libb.so" está mal.

Supongamos que el liba.c tiene el siguiente contenido:

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

Y libb.c tiene el siguiente:

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);
}

Y 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;
}

Al enlazar libb.so:

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

El enlazador no genera ningún mensaje de error que liba_nonexistent_func no se pueda resolver, en su lugar simplemente silenciosamente generar una biblioteca compartida rota libb.so. El comportamiento es el mismo que haría una biblioteca estática (libb.a) con ar que no resuelve los símbolos de la biblioteca generada también.

Pero cuando intentas vincular test:

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

Se obtiene el error:

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

Detectar este error no sería posible si ld no escaneara recursivamente todas las bibliotecas compartidas. Así que parece que la respuesta a la pregunta es la misma que dije anteriormente: ld necesidades -rpath-link para asegurarse de que el ejecutable vinculado se puede cargar más tarde mediante dynamic loaded. Sólo un chequeo de cordura.

UPD2

Tendría sentido verificar las referencias no resueltas lo antes posible (al enlazar libb.so), pero ld por algunas razones no hace esto. Es probablemente para permitir hacer dependencias cíclicas para bibliotecas compartidas.

liba.c puede tener la siguiente implementación:

int libb_func(int i);

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

So liba.so uses libb.so y libb.so usa liba.so (mejor nunca hacer tal cosa). Esto compila y funciona con éxito:

$ 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

Aunque readelf dice que liba.so no necesita 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]

Si ld comprueba si hay símbolos sin resolver durante el enlace de una biblioteca compartida, el enlace de liba.so no sería posible.

Tenga en cuenta que he usado -rpath en lugar de -rpath-link. La diferencia es que - rpath-link se usa en el momento del enlace solo para comprobar que todos los símbolos en el ejecutable final se pueden resolver, mientras que - rpath en realidad incrusta la ruta que especifique como parámetro en el ELF:

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

Así que ahora es posible ejecutar test si las bibliotecas compartidas (liba.so y libb.so) se encuentran en su directorio de trabajo actual (./). Si acaba de usar - rpath-link no habría tal entrada en test ELF, y tendría que agregar la ruta a las bibliotecas compartidas al archivo /etc/ld.so.conf o al archivo LD_LIBRARY_PATH variable de entorno.

UPD3

En realidad es posible verificar si hay símbolos sin resolver durante la vinculación de la biblioteca compartida, --no-undefined Se debe usar la opción para hacer eso:

$ 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

También encontré un buen artículo que aclara muchos aspectos de vincular bibliotecas compartidas que dependen de otras bibliotecas compartidas: Mejor comprensión de las dependencias secundarias de Linux resolviendo con ejemplos.