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 ldd output is misleading (at least for binaries which do not use the system ld-linux).
About 10 years ago, ldd used the actual program interpreter "baked into" the binary (the some_absoulute_path/ld-linux-x86-64.so.2 here).
However, this was deemed a security risk, because a root user might run ldd some-foreign-binary and that would cause the "baked in interpreter" to run as root, which isn't necessarily what the system administrator expected.
So now ldd uses the system ld-linux regardless of "baked in" interpreter, and that causes the "wrong" output here:
some_absoulute_path/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 ...
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" interpreter some_absoulute_path/ld-linux-x86-64.so.2.
To get accurate ldd result, you should run the ldd that matches some_absoulute_path/ld-linux-x86-64.so.2. Here it's probably /opt/compiler/gcc-8.2/bin/ldd.