Dziwne ścieżki wyszukiwania łącznika gcc - linux, gcc, ld

Bieganie gcc z -Wl,--verbose drukuje rzeczy takie jak

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

Czy istnieje powód, dla którego ścieżki te muszą mieć wiele ../ w nich? Na przykład dlaczego /foo/gcc-6.3.0/lib64/../lib64/libm.so nie łatwe /foo/gcc-6.3.0/lib64/libm.so? Ponadto niektóre dłuższe ścieżki rozszerzają się do tego samego, np. /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../../lib64/libm.so i /foo/gcc-6.3.0/lib/../lib64/libm.so.

Ponadto istnieje wyraźny brak /foo/gcc-6.3.0/lib, podczas gdy większość bibliotek jest zainstalowanych w lib zamiast lib64.

Odpowiedzi:

Znalazłem dwa podobne pytania:

Dlaczego g ++ wygląda w LIBRARY_PATH /../ lib64 i gdzie jest to udokumentowane?

g ++ wyszukiwania /lib/../lib/, then / lib /

Komentarz tutaj rzuca światło na to, co decyduje o formowaniu tych ścieżek.

Nie można jednak odpowiedzieć, dlaczego tak wiele z tych ścieżek jest używanych, nawet jeśli dotyczą one tego samego katalogu.

Biblioteki w /foo/gcc-* Jest dostarczony przez gcc-* pakiety będące dowiązaniem symbolicznym do rzeczywistych bibliotek podanych w /lib64/ lub /lib.

Te dowiązania symboliczne zapewniają ukierunkowane wsparcie dla gcc.

Rzeczywiste biblioteki zawierają biblioteki współdzielone.

Brać gcc-objc jako przykład i biblioteka libobjc na to wskazuje.

$ 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

Teraz spójrzmy na opis tych pakietów.

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