What is the dynamic linker in GNU/Linux systems?

When we work with C/C++ code, our output will be generated as ELF (Executable and Linkable Format, for Linux), or PE (Portable Executable, for MS Windows).  As you remember we can link our application either statically, or dynamically.  SO (Shared Object) *.so files are the dynamic library files for use with dynamic linking, and I’ll share an issue regarding the dynamic linker configuration in this article. Although most of the Linux distributions uses /lib/ld-linux.so.3, or /lib64/ld-linux-x86-64.so.2, it might be different in your Linux distribution, therefore this article would be helpful for those who need to work with cross development tools.

The code segment on the left is a simple test application, and I built the code with a standard compilation command:

$ gcc -o linker-test linker-test.c -Wall

then copied into the target directory called “~/dynamic-linker“

/* linker-test.c */
#include <stdio.h>

int
main(int argc, char *argv[])
{
    printf("Linker Test Application.\n");
    return 0;
}

Although the linker-test file can be listed in the working directory along with the proper permissions and the execution setting, I got the message below:

bash: ./linker-test: No such file or directory

This is a very strange behavior as you can image.

Let’s investigate the executable with readelf command.

bolat@pc ~/dynamic-linker $ ls -al
total 40
drwxr-xr-x 2 vork vork 4096 Sep 26 17:18 .
drwxr-xr-x 4 vork vork 4096 Sep 26 17:16 ..
-rwxr-xr-x 1 vork vork 9752 Sep 26 17:18 linker-test
-rw-r--r-- 1 vork vork  114 Sep 26 17:16 linker-test.c

bolat@pc ~/dynamic-linker $ ./linker-test 
bash: ./linker-test: No such file or directory

bolat@pc ~/dynamic-linker $ readelf --program-headers linker-test

Elf file type is EXEC (Executable file)
Entry point 0x400420
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000000b 0x000000000000000b  R      1
      [Requesting program interpreter: /lib/ld.so]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000070c 0x000000000000070c  R E    200000
  LOAD           0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x0000000000000228 0x0000000000000230  RW     200000
  DYNAMIC        0x0000000000000e28 0x0000000000600e28 0x0000000000600e28
                 0x00000000000001d0 0x00000000000001d0  RW     8
  NOTE           0x0000000000000244 0x0000000000400244 0x0000000000400244
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x00000000000005e0 0x00000000004005e0 0x00000000004005e0
                 0x0000000000000034 0x0000000000000034  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000000e10 0x0000000000600e10 0x0000000000600e10
                 0x00000000000001f0 0x00000000000001f0  R      1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .init_array .fini_array .jcr .dynamic .got

As you can observe at the line 14, the dynamic linker is set to “/lib/ld.so”, and this is not the default linker for my native development environment.  You can check your linker by looking your /lib{,64}/ld-*.so files.

bolat@pc /lib $ ls -al ld-*
lrwxrwxrwx 1 root root 25 Jun  5  2020 ld-linux.so.2 -> i386-linux-gnu/ld-2.23.so

bolat@pc /lib64 $ ls -al ld-*
lrwxrwxrwx 1 root root 32 Jun  5  2020 ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.23.so

In order to solve this dynamic linker issue, you can directly define the linker with -Wl,–dynamic-linker=/path/to/ld-so parameter.  Sample gcc parameter is shown below

bolat@pc ~/dynamic-linker $ gcc -o linker-test linker-test.c -Wall -g -Wl,--dynamic-linker=/lib64/ld-linux-x86-64.so.2
bolat@pc ~/dynamic-linker $ ./linker-test 
Linker Test Application.

There are plenty of tutorials for cross-compilation and dynamic linking for C/C++ applications online, but I wanted to emphasize the issues related to dynamic loaders which can cause head scratching issues during the cross-development in this article.  Although it seems trivial, these type of problems can waste a lot of time for debugging.