I have a small C++ program which I am compiling on a ubuntu machine. The program runs fine on the same machine, but when I copy and try to run on a different linux system it printed

./prog1 : No such file or directory.

Further probing I realized the VDSO (linux-vdso.so.1) support is not enabled on the kernel running in target linux machine.

Below is the output of ldd of the program from my linux machine.

linux-vdso.so.1 =>  (0x00007fffda425000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6ce9114000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6ce8efe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6ce8b38000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6ce8832000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6ce9432000)

Now I want to know how do I compile my code in my ubuntu pc to run this on the target ?

_______________________________________________-

new EDITS

the binary is marked for execution so tat is not the problem. and VDSO is not definetly the issue because I found the target kernel supports that.

Now I found a difference between the target kernel and the kernel installed on my ubuntu PC.

From target .... xmllint: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=9dc806b0866749772b0d2458ae74e7cea6e9a4aa, stripped

From Ubuntu ----- prog1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=4ab095886f476674a7bf30c11d5479f7daa91001, not stripped

So should I have compile my code with the higher kernel version i.e 2.6.32 ?

  • 1
    The error suggests that your executable doesn't exist. What makes you think the issue is vdso-related? – terdon Aug 24 '16 at 10:29
  • What does ldd prog1 print on the other system (the one where it doesn’t run)? – Stephen Kitt Oct 26 '17 at 14:20

linux-vdso.so isn't a normal shared library. It's a virtual library that the kernel automatically maps into the address space of each process to provide some syscalls without a full context switch and to ease syscalls in general. You can read more on the manpage (online here). Since it's not loaded from a file ldd doesn't show you a path, but since it shows the adress it get's mapped at you can be sure it's loaded correctly.

Since all libraries are found, the most likely reason is that the file simply isn't marked executable (chmod +x).

  • the binary is marked for execution. and VDSO is not definetly the issue because I found the target kernel supports that. Now I found a difference between the target kernel and the kernel installed on my ubuntu. – prabhu Aug 25 '16 at 5:07

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.