1

Running gcc with -Wl,--verbose prints things like

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

Is there a reason why these paths need to have a bunch of ../ in them? For example, why is /foo/gcc-6.3.0/lib64/../lib64/libm.so not simply /foo/gcc-6.3.0/lib64/libm.so? Also, some of the longer paths expand to the same thing, e.g. /foo/gcc-6.3.0/lib/gcc/x86_64-redhat-linux/6.3.0/../../../../lib64/libm.so and /foo/gcc-6.3.0/lib/../lib64/libm.so.

Also, there's a marked lack of /foo/gcc-6.3.0/lib, while most libraries are installed in lib rather than lib64.

SU3
  • 5,064
  • 3
  • 35
  • 66

2 Answers2

0

I found two similar questions asked here:

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

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

The comment here sheds light on what determines how these paths are formed.

These, however, don't answer why so many of these paths are used, even though they resolve to the same directory.

Community
  • 1
  • 1
SU3
  • 5,064
  • 3
  • 35
  • 66
0

The libraries in the /foo/gcc-* is provided by gcc-* packages which is a symlink to the actual libraries provided in /lib64/ or /lib.

These symlinks provides targeted support for gcc.

The actual libraries contain the shared libraries.

Take gcc-objc as an example and the library libobjc that it points to.

$ 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

Now let's look at the description of these packages.

$ 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.
alvits
  • 6,550
  • 1
  • 28
  • 28