when I run 'ldd some_executable_file', it shows dependencies required by this exe, like "libm.so.6 => /usr/lib64/libm.so.6 (0x00007ff2eaf52000)". while some dependencies in the list appearing in the form "some_absoulute_path/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007ff2eba92000)",it seems that the left side file does not points to the right side file
according to some tests, the left side file was choosed as dependency path while the right side file was not, so what does the symbol "=>" mean?
The problem is that
lddoutput is misleading (at least for binaries which do not use the systemld-linux).About 10 years ago,
lddused the actual program interpreter "baked into" the binary (thesome_absoulute_path/ld-linux-x86-64.so.2here).However, this was deemed a security risk, because a root user might run
ldd some-foreign-binaryand that would cause the "baked in interpreter" to run as root, which isn't necessarily what the system administrator expected.So now
ldduses the systemld-linuxregardless of "baked in" interpreter, and that causes the "wrong" output here:If you were to actually run the binary, it wouldn't use
/lib64/ld-linux-x86-64.so.2; it would use the actual "baked in" interpretersome_absoulute_path/ld-linux-x86-64.so.2.To get accurate
lddresult, you should run thelddthat matchessome_absoulute_path/ld-linux-x86-64.so.2. Here it's probably/opt/compiler/gcc-8.2/bin/ldd.