fichier crti.o manquant

Question

Je construis un projet en utilisant une chaîne d'outils GNU et tout fonctionne correctement jusqu'à ce que je puisse le relier, où l'éditeur de liens se plaint qu'il est manquant / impossible à trouver crti.o. Ce n’est pas un de mes fichiers d’objets, il semble être lié à libc mais je ne comprends pas pourquoi il aurait besoin de cela libc.a, n’utiliserait-il pas un fichier de bibliothèque, par exemple. .o?

Je fais de la compilation croisée 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?

gcc se trouve dans l'un des chemins de recherche des bibliothèques, mais doit-il rechercher le fichier ld dans le chemin des bibliothèques?

Le chemin de recherche est-il identique pour <=> et <=>?

Answer 1

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 à placer 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, il suffit de les construire.

Vous ne faites pas de compilation croisée, n'est-ce pas?

Si vous effectuez une compilation croisée, le problème réside généralement dans le fait que le chemin de recherche de gcc ne correspond pas à l'emplacement où se trouve 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 voir si crti.o se trouve dans l’un de ces chemins.

La liaison se fait en réalité par ld mais ses chemins lui sont transmis par gcc. Le moyen le plus rapide de savoir ce qui se passe est de compiler un programme helloworld.c et de le visualiser 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, car vous pouvez voir 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 constatez de nombreuses tentatives pour open(...crti.o) = -1 ENOENT, ld vous embrouillez et vous souhaitez savoir d'où vient le chemin d'ouverture.

Answer 2

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 chercherait d'abord un chemin & Ls; sysroot & Gt; / usr / lib et que, le cas échéant, il envisagerait même de & Lt ; racine du système > / usr / lib64 .

Est-ce un bug dans l'éditeur de liens? Ou ce comportement est-il documenté quelque part?

Answer 3

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 et j'installe le package de développement:

sudo apt-get install libc6-dev

Si vous trouvez des bibliothèques à lire ici

Answer 4

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: -)

Answer 5

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’avais besoin de compiler un simple fichier C.

Answer 6

Je rencontre le même type de problème lors d’une installation par défaut d’Ubuntu 8.04. Je devais obtenir les en-têtes / fichiers de développement libc manuellement pour que cela fonctionne.

Answer 7

Ceci a résolu pour moi (compilation croisée de pjsip pour ARM):

export LDFLAGS='--sysroot=/home/me/<path-to-my-sysroot-parent>/sysroot'