Seltsam gcc Linker Suchpfade

Question

Lauf gcc mit -Wl,--verbose druckt Dinge wie

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 

Gibt es einen Grund, warum diese Wege müssen eine Reihe von ../ in ihnen haben? Zum Beispiel, warum ist /foo/gcc-6.3.0/lib64/../lib64/libm.so nicht einfach /foo/gcc-6.3.0/lib64/libm.so? Außerdem erweitern sich einige der längeren Pfade zu der gleichen Sache, z. /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../../lib64/libm.so und /foo/gcc-6.3.0/lib/../lib64/libm.so.

Auch gibt es einen deutlichen Mangel an /foo/gcc-6.3.0/lib, während die meisten Bibliotheken in lib statt lib64 installiert sind.

Answer 1

fand ich zwei ähnliche hier gestellten Fragen:

Why does g++ look in LIBRARY_PATH/../lib64 and where is this documented?

g++ searches /lib/../lib/, then /lib/

Der Kommentar here Schuppen auf Licht, was bestimmt, wie diese Wege gebildet werden.

Diese antworten jedoch nicht, warum so viele dieser Pfade verwendet werden, obwohl sie in dasselbe Verzeichnis aufgelöst werden.

Answer 2

Die Bibliotheken im /foo/gcc-* durch gcc-* Paketen bereitgestellt, die ein symbolischer Link zu den tatsächlichen Bibliotheken in /lib64/ oder /lib vorgesehen ist.

Diese Symlinks bieten gezielte Unterstützung für gcc.

Die aktuellen Bibliotheken enthalten die gemeinsam genutzten Bibliotheken.

Nehmen Sie gcc-objc als ein Beispiel und die Bibliothek libobjc, auf die es zeigt.

$ 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 

Nun schauen wir uns die Beschreibung dieser Pakete an.

$ 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.