Rutas extrañas de búsqueda del enlazador de gcc: linux, gcc, ld

Corriendo gcc con -Wl,--verbose imprime cosas como

attempt to open /foo/gcc-6.3.0/lib64/../lib64/libm.so failed
attempt to open /foo/gcc-6.3.0/lib64/../lib64/libm.a failed
attempt to open /foo/gcc-6.3.0/lib/x86_64-redhat-linux/6.3.0/libm.so failed
attempt to open /foo/gcc-6.3.0/lib/x86_64-redhat-linux/6.3.0/libm.a failed
attempt to open /foo/gcc-6.3.0/lib/../lib64/libm.so failed
attempt to open /foo/gcc-6.3.0/lib/../lib64/libm.a failed
attempt to open /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/libm.so failed
attempt to open /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/libm.a failed
attempt to open /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../x86_64-redhat-linux/6.3.0/libm.so failed
attempt to open /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../x86_64-redhat-linux/6.3.0/libm.a failed
attempt to open /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../../lib64/libm.so failed
attempt to open /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../../lib64/libm.a failed
attempt to open /lib/../lib64/libm.so failed
attempt to open /lib/../lib64/libm.a failed
attempt to open /usr/lib/../lib64/libm.so succeeded

¿Hay alguna razón por la que estos caminos deban tener un montón de ../ ¿en ellos? Por ejemplo, ¿por qué es /foo/gcc-6.3.0/lib64/../lib64/libm.so no simplemente /foo/gcc-6.3.0/lib64/libm.so? Además, algunos de los caminos más largos se expanden a la misma cosa, por ejemplo, /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../../lib64/libm.so y /foo/gcc-6.3.0/lib/../lib64/libm.so.

Además, hay una marcada falta de /foo/gcc-6.3.0/lib, mientras que la mayoría de las bibliotecas están instaladas en lib más bien que lib64.

Respuestas

Encontré dos preguntas similares hechas aquí:

¿Por qué se ve g ++ en LIBRARY_PATH /../ lib64 y dónde se documenta esto?

g ++ busca en /lib/../lib/, luego / lib /

El comentario aquí arroja luz sobre lo que determina cómo se forman estos caminos.

Estos, sin embargo, no responden por qué se usan tantas de estas rutas, aunque se resuelvan en el mismo directorio.

Las bibliotecas en el /foo/gcc-* Es provisto por gcc-* paquetes que es un enlace simbólico a las bibliotecas reales proporcionadas en /lib64/ o /lib.

Estos enlaces simbólicos proporcionan soporte dirigido para gcc.

Las bibliotecas reales contienen las bibliotecas compartidas.

Tomar gcc-objc como ejemplo y la biblioteca libobjc que apunta a

$ rpm -ql gcc-objc
<snip>
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/objc/thr.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/objc/typedstream.h
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libobjc.a
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libobjc.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.7
<snip>

$ ls -l /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libobjc.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libobjc.so -> ../../../../lib64/libobjc.so.2

$ rpm -ql libobjc
/usr/lib64/libobjc.so.2
/usr/lib64/libobjc.so.2.0.0

Ahora veamos la descripción de estos paquetes.

$ rpm -qi gcc-objc
gcc-objc provides Objective-C support for the GCC.
Mainly used on systems running NeXTSTEP, Objective-C is an
object-oriented derivative of the C language.

$ rpm -qi libobjc
This package contains Objective-C shared library which is needed to run
Objective-C dynamically linked programs.