The ldd command can list the dynamic library and the path of the dynamic library that the executable program depends on. It can be convenient to help check some compilation problems.
However, I recently encountered a problem that the execution of ldd shows that it is not a dynamic executable. As shown below
There are several possible reasons for this problem.
- The file is indeed not an executable program, or a dynamic library, and it is not an elf file under Linux. For example, copy the program under windows to execute under linux.
- The file is 32-bit and the system is 64-bit, or vice versa, the file is 64-bit and the system is 32-bit.
- The file is of x86 architecture, but the system is of arm architecture or vice versa, cross-compiled files often have this problem.
In the above three cases, you can use the file command to confirm the file format.
As follows, you can see that the file is in elf format, 64-bit, and X86-64-bit. If the system used matches it, there will be no problem.
- There is another situation, which is also encountered recently, which is quite special. The version of ldd is inconsistent with the version of the compiler. The program is compiled with gcc version 7.5,
and the ldd in the actual environment is compiled with gcc version 10.3. If the version does not match, there will be a problem. You can check whether the version of ldd is consistent with the version of ldd in the program compilation environment.
There is another way to view the version of libc.so. The version of ldd corresponds to the version of libc.so. You can view the version by running libc.so, as shown below.
This involves a more interesting point, libc.so is not only a dynamic library, but also can be executed separately. Interested students can find out.
