`bash: ./un.: Aucun fichier ou répertoire` sur l'exécution du fichier exécutable généré par `ld`

Ici est un Hello World code en C:

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

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

Je le compiler en tant que gcc a.c, qui produit a.out comme prévu et ./a.out imprime Hello world... comme prévu.

Maintenant, si je dois le compiler et lier séparément:
gcc -c a.c; ld -lc a.o, de l'exécution du a.out produit comme ./a.out je reçois le message:

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

J'ai Googlé cette erreur et il semble que ce qui se passe lorsque l'exécutable produit est un 32 bits, l'ELFE et l'architecture de la machine est de 64 bits.

Je fais tourner une machine 64 bits et en cours d'exécution file a.out donne:

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

Pourquoi cela se produit?

EDIT:

Sortie de uname -m

$ uname -m
x86_64

Sortie de 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 produit a.out qui fonctionne correctement.

Une machine 64 bits ne signifie pas nécessairement un OS 64 bits. Quel est le résultat de uname -m?
Ce n' ldd a.out produire? Ce qui se passe lorsque vous ne gcc a.c?
Ajouté le sorties, des modifications à la question
vous pouvez exécuter la commande: gcc-v un.c et vérifier le lien de la scène (avez-vous besoin de lien avec l'objet de démarrage habituellement crt0.o)
Pourquoi ne voulez-vous pas laisser gcc poignée de la liaison?

OriginalL'auteur pratyaksh | 2015-11-28