fichier crti.o manquant
Je construis un projet en utilisant une chaîne d'outil GNU et tout fonctionne correctement jusqu'à ce que je parvienne à le lier, où l'éditeur de liens se plaint qu'il est manquant/ne trouve pas crti.o. Ce n'est pas l'un de mes fichiers objet, il semble être lié à libc mais je ne comprends pas pourquoi il aurait besoin de ce crti.o, n'utiliserait-il pas un fichier de bibliothèque, par exemple. libc.a?
Je compile pour la plate-forme du bras. J'ai le fichier dans la boîte à outils, mais comment puis-je l'inclure dans l'éditeur de liens?
crti.o se trouve dans l'un des chemins de recherche des bibliothèques, mais doit-il rechercher le fichier .o dans le chemin des bibliothèques?
Le chemin de recherche est-il le même pour gcc et ld?
crti.o est la bibliothèque d'amorçage, généralement assez petite. Il est généralement lié statiquement à votre binaire. Il devrait être trouvé dans /usr/lib.
Si vous exécutez une distribution binaire, ils ont tendance à mettre tous les éléments de développement dans des packages -dev (par exemple, libc6-dev), car il n'est pas nécessaire d'exécuter des programmes compilés, mais simplement de les construire.
Vous n'êtes pas cross-compilation, n'est-ce pas?
Si vous effectuez une compilation croisée, le problème est généralement lié au fait que le chemin de recherche de gcc ne correspond pas à l'emplacement de votre fichier crti.o. Il aurait dû être construit quand la chaîne d'outils était. La première chose à vérifier est gcc -print-search-dirs et de voir si crti.o se trouve dans l’un de ces chemins.
La liaison est en fait faite par ld mais son chemin lui est transmis par gcc. Le moyen le plus rapide de savoir ce qui se passe est de compiler un programme helloworld.c et de le regarder pour voir ce qui est transmis à LD et voir ce qui se passe.
strace -v -o log -f -e trace=open,fork,execve gcc hello.c -o test
Ouvrez le fichier journal et recherchez crti.o, comme vous pouvez le voir sur mon compilateur non croisé:
10616 execve("/usr/bin/ld", ["/usr/bin/ld", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=both", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o"
, "test", "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "-L/usr/lib/gcc/x86_64-linux-g
nu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/lib/../lib", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu
/"..., "/tmp/cc4rFJWD.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_
64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."...], "COLLECT_GCC=gcc", "COLLECT_GCC_OPTIONS=\'-o\' \'test\' "..., "COMPILER_PATH=/usr/lib/gcc/x86_6"..., "LIBRARY_PATH=/usr/lib/gcc/x86_64"..., "CO
LLECT_NO_DEMANGLE="]) = 0
10616 open("/etc/ld.so.cache", O_RDONLY) = 3
10616 open("/usr/lib/libbfd-2.18.0.20080103.so", O_RDONLY) = 3
10616 open("/lib/libc.so.6", O_RDONLY) = 3
10616 open("test", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crt1.o", O_RDONLY) = 4
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crti.o", O_RDONLY) = 5
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/crtbegin.o", O_RDONLY) = 6
10616 open("/tmp/cc4rFJWD.o", O_RDONLY) = 7
Si vous voyez un tas de tentatives de open(...crti.o) = -1 ENOENT, ld est confus et vous voulez voir d'où vient le chemin qu'il a ouvert ...
J'ai eu le même problème lors de la compilation croisée. crti.o était dans <sysroot>/usr/lib64 mais l'éditeur de liens ne le trouverait pas.
Il s'avère que la création d'un répertoire vide <sysroot>/usr/lib a résolu le problème. Il semble que l’éditeur de liens recherche un chemin <sysroot>/usr/lib first, et ne considère même que s’il existe <sysroot>/usr/lib64 .
Est-ce un bug dans l'éditeur de liens? Ou ce comportement est-il documenté quelque part?
Dans mon cas, Linux Mint 18.0/Ubuntu 16.04, je n'ai pas du tout crti.o:
$ find /usr/ -name crti*
Je ne trouve rien alors j'installe le package de développeur:
Sudo apt-get install libc6-dev
Si vous trouvez des libs lisez ici
J'ai eu un problème similaire avec un compilateur croisé mal configuré. Je l'ai contourné comme ça:
/home/rob/compiler/usr/bin/arm-linux-gcc --sysroot=/home/rob/compiler hello.c
Cela suppose que/lib,/usr/include et ainsi de suite existent à l'emplacement indiqué par l'option sysroot. Ce n'est probablement pas ainsi que les choses sont supposées être faites, mais cela m'a évité des problèmes lorsque j'ai eu besoin de compiler un fichier C simple.
OK, j'ai dû réinstaller la chaîne d'outils pour que les fichiers manquants soient inclus. Cela semble étrange car il aurait dû le trouver sur le chemin gcc. Le principal problème, je suppose, c’était que j’avais une quinzaine de fichiers crti.o différents sur mon ordinateur et que je ne désignais pas le bon. Je ne fais toujours pas depuis mais ça fonctionne maintenant :-) Merci pour votre aide :-)
Je reçois le même genre de problème sur une installation Ubuntu 8.04 par défaut. Je devais obtenir les en-têtes/fichiers de développeur libc manuellement pour que cela fonctionne.
Ceci a résolu pour moi (compilation croisée de pjsip pour ARM):
export LDFLAGS='--sysroot=/home/me/<path-to-my-sysroot-parent>/sysroot'