`bash: ./a.out: No such file or directory` on running executable produced by `ld`

Question

Here is a Hello World code in C:

// a.c
#include <stdio.h>

int main() {
    printf("Hello world\n");
    return 0;
}

I compile it as gcc a.c, which produces a.out as expected and ./a.out prints Hello world... as expected.

Now if I do the compile and link separately: gcc -c a.c; ld -lc a.o, it run the a.out produced as ./a.out I get the message:

bash: ./a.out: No such file or directory

I Googled that error and it seems that happens when the executable produced is a 32-bit ELF and the machine architecture is 64-bit.

I'm running a 64-bit machine and running file a.out gives:

a.out: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Why does this happen?

EDIT:

Output of uname -m

$ uname -m
x86_64

Output of ldd a.out

$ ldd a.out
    linux-vdso.so.1 =>  (0x00007ffeeedfb000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa13a7b8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa13abab000)

gcc a.c produces a.out which runs correctly.

Answer 1

ld -lc a.o

There are several things wrong with this command line:

1. In general, user-level code should never use ld directly, and always use appropriate compiler front end (gcc here) to perform the link.

   As you have discovered, the link command line that gcc constructs is quite complicated, and the command line that you've accepted in Joan Esteban's answer is wrong.

   If you want to see the actual link command, examine output from gcc -v a.o.

   Also note that link command changes significantly when you change gcc command only slightly (e.g. some OSes require different crt1.o depending on whether you are linking multi-threaded executable or not), and the command line is always OS-specific (which is one more reason to never use ld directly).

2. Libraries should follow object files on command line. So ld -lc a.o is never correct, and should always be (a variant of) ld a.o -lc. Explanation.