Deeply understand the reason behind the prompt "No such file or directory" when executing a file in Linux

1 Background

Recently, I have been studying how to build a compilation system (not supporting apt) in the Linux system of the ZC706-ARM development board. I happened to find that the company has an Nvidia ARM development board with an ubunut system (supporting apt). At this time, an idea came to my mind: can the program compiled on the Nvidia board run on the ZC706 board?

2 Process

In NVIDIA's development board, gcc ac generates a.out, and then copies it to ZC706 and executes it, and "No such file or directory" appears

The reasons I encountered before are as follows:

• The file itself does not exist or the file is damaged
• No execution permission (chmod 777 xxx)
• The system bit number is different from the program bit number

However, after the following process, it was found that ZC706 lacked the specified loader for the xx program:

1. Eliminate file corruption and other issues --> Regenerate copy verification
2. Eliminate program permission issues --> chmod 777 xx && ls -all
3. Eliminate architecture issues through unanme -a
4. Use commands such as readelf file to compare the differences between the normally executed files and the incorrectly executed files

Verification process:

a.out is compiled by NVIDIA gcc and zc706 has the above problem | b.out is cross-compiled by x86 ubunut and can be executed normally

Later, I found through Google that the loader can also cause this phenomenon. From the following, we can find that the difference between the two is mainly in the interpreter

Solution:

1. Unify the relationship between compiler and library

2. Create a soft link ln -s /lib/ld-linux.so.3 /lib/ld-linux-armhf.so.3

3. When compiling the program, add the -static option to statically link the program, that is, do not use dynamic libraries

root@tegra-ubuntu:~# readelf -h a.out
ELF Header:
 Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
 Class: ELF32
 Data: 2's complement, little endian
 Version: 1 (current)
 OS/ABI: UNIX - System V
 ABI Version: 0
 Type: EXEC (Executable file)
 Machine: ARM
 Version: 0x1
 Entry point address: 0x8315
 Start of program headers: 52 (bytes into file)
 Start of section headers: 4500 (bytes into file)
 Flags: 0x5000402, has entry point, Version5 EABI, hard-float ABI
 Size of this header: 52 (bytes)
 Size of program headers: 32 (bytes)
 Number of program headers: 9
 Size of section headers: 40 (bytes)
 Number of section headers: 30
 Section header string table index: 27
root@tegra-ubuntu:~# readelf -h b.out
ELF Header:
 Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
 Class: ELF32
 Data: 2's complement, little endian
 Version: 1 (current)
 OS/ABI: UNIX - System V
 ABI Version: 0
 Type: EXEC (Executable file)
 Machine: ARM
 Version: 0x1
 Entry point address: 0x86bc
 Start of program headers: 52 (bytes into file)
 Start of section headers: 4136 (bytes into file)
 Flags: 0x5000202, has entry point, Version5 EABI, soft-float ABI
 Size of this header: 52 (bytes)
 Size of program headers: 32 (bytes)
 Number of program headers: 8
 Size of section headers: 40 (bytes)
 Number of section headers: 31
 Section header string table index: 28
root@tegra-ubuntu:~# readelf -l helloworld | grep interpreter
readelf: Error: 'helloworld': No such file
root@tegra-ubuntu:~# readelf -l a.out | grep interpreter
   [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
root@tegra-ubuntu:~# readelf -l b.out | grep interpreter
   [Requesting program interpreter: /lib/ld-linux.so.3] 

3 Introduction to the ld loader

Linux uses this ld-linux.so* (Ubuntu on virtual machine x86 uses ld-linux.so2) to load (actually this is just a link) other libraries. So this library must be placed in linux/lib. For others, we usually put shared libraries in the /lib path, which is also the system's default search path.

The search path order of Linux shared libraries is:
1. The dynamic library search path specified when compiling the target code: specify -Wl,-rpath=path when compiling
2. Dynamic library search path specified by the environment variable LD_LIBRARY_PATH
3. Dynamic library search path specified in the configuration file /etc/ld.so.conf
4. Default dynamic library search path /lib
5. The default dynamic library search path is /usr/lib

Notice:

1. Some development boards will find that /etc does not have ld.so.conf. At this time, running ldconfig will prompt "ldconfig: Warning: ignoring configuration file that cannot be opened: /etc/ld.so.conf: No such file or directory"

Solution: Add the library to the environment variables, then ldconfig -v (/sbin/ldconfig: relative path `–v' used to build cache)

2. Shared library cnnot open shared object

Test whether it is dynamically linked. If libtest.so is listed, then the link should be normal.

At this time, libtest.so cannot be found. There is a problem with the search path of the dynamic link library. Therefore, just add the dynamic library search location above.

3 The ldconfig command mainly searches for sharable dynamic link libraries (the format is as described above, lib*.so*) in the default search directories (/lib and /usr/lib) and the directories listed in the dynamic library configuration file /etc/ld.so.conf, and then creates the connection and cache files required by the dynamic loader (ld.so)

4 LD_LIBRARY_PATH: This environment variable indicates the path where the dynamic linker can load dynamic libraries. If you have root privileges, you can modify the /etc/ld.so.conf file and then call /sbin/ldconfig to achieve the same purpose. However, if you do not have root privileges, you can only use the method of outputting LD_LIBRARY_PATH using the bash command.)

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.