Frage

Ich baue ein Projekt GNU-Toolkette mit und alles funktioniert gut, bis ich zu verknüpfen sie bekommen, wo der Linker beklagt, dass es fehlt / nicht crti.o finden. Dies ist nicht eine meiner Objektdateien, so scheint es, bezogen werden libc aber ich kann nicht verstehen, warum es diese crti.o brauchen würde, wäre es nicht eine Bibliotheksdatei verwenden, z.B. libc.a?

Ich bin Kreuzkompilierung für die ARM-Plattform. Ich habe die Datei in der Toolchain, aber wie bekomme ich den Linker um es zu schließen?

crti.o ist auf einem der Suchpfad ‚Bibliotheken‘, aber sollte es für .o Datei auf dem Bibliothekspfad aussehen?

Ist der Suchpfad für gcc und ld?

War es hilfreich?

Lösung

crti.o ist die Bootstrap-Bibliothek, in der Regel recht klein. Es ist in der Regel statisch in der Binärdatei verbunden. Es sollte in /usr/lib gefunden werden.

Wenn Sie mit einer Binärdistribution sie neigen dazu, alle Entwickler Sachen in -dev-Pakete zu setzen (z libc6-dev), da es nicht kompilierte Programme zu laufen braucht, nur um sie zu bauen.

Sie sind keine Kreuz Compilierung sind Sie?

Wenn Sie Cross-Kompilierung es ist in der Regel ein Problem mit dem gcc-Suchpfad nicht passend, wo Ihre crti.o ist. Es sollte gebaut worden, wenn die Werkzeugkette war. Das erste, was zu überprüfen ist gcc -print-search-dirs und sehen, ob crti.o in einem dieser Wege ist.

Die Verknüpfung wird tatsächlich von ld getan, aber es hat seine Wege, um es von gcc weitergegeben. Wahrscheinlich der schnellste Weg, um herauszufinden, was los ist, ein HelloWorld.c Programm kompiliert und strace es zu sehen, was zu ld geführt wird und sehen, was los ist.

strace -v -o log -f -e trace=open,fork,execve gcc hello.c -o test

Öffnen Sie die Protokolldatei und die Suche nach crti.o, wie Sie meinen nicht-Cross-Compiler sehen:

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

Wenn Sie eine Reihe von Versuchen, sehen open(...crti.o) = -1 ENOENT wird ld verwirrt und Sie wollen sehen, wo der Weg es zu öffnen kamen aus ...

Andere Tipps

Ich hatte das gleiche Problem, während Cross-Compilierung. crti.o war in / usr / lib64 , aber die Linke würde es nicht finden.

Es stellt sich heraus, dass ein leeres Verzeichnis erstellen / usr / lib das Problem behoben. Es scheint, dass der Linker für einen Weg suchen würde / usr / lib zuerst, und nur dann, wenn sie es wäre existiert sogar überlegen / usr / lib64 .

Ist das ein Fehler in den Linker? Oder ist dieses Verhalten dokumentiert irgendwo?

In meinem Fall Linux Mint 18.0/Ubuntu 16.04, ich habe keine crti.o überhaupt:

$ find /usr/ -name crti*

Ich finde nichts so installiere ich Entwickler-Paket:

sudo apt-get install libc6-dev

Wenn Sie einige Libs href="https://stackoverflow.com/a/16605434/4632019"> lesen

OK hatte ich die Werkzeugkette neu zu installieren, so dass die fehlenden Dateien dann enthalten waren. Es scheint seltsam, da sie es auf dem gcc Weg gefunden haben sollten. Das Hauptproblem war ich denke, dass ich 15 oder so unterschiedliche crti.o Dateien auf meinem Computer und nicht an den richtigen Punkt. Noch nicht machen, da aber es funktioniert jetzt :-) Vielen Dank für Ihre Hilfe: -)

Ich hatte ein ähnliches Problem mit einem schlecht Set-up Cross-Compiler. Ich habe um es in etwa so:

/home/rob/compiler/usr/bin/arm-linux-gcc --sysroot=/home/rob/compiler hello.c

Dies setzt voraus, / lib, / usr / include und so weiter gibt es in der Lage, auf die die sysroot Option. Dies ist wahrscheinlich nicht, wie die Dinge sollen getan werden, aber es hat mich aus der Patsche, wenn ich eine einfache C-Datei zu kompilieren benötigt.

Ich bekomme die gleiche Art von Problem auf einem Standard-Ubuntu 8.04 installieren. Ich musste die libc Entwickler Header / Dateien erhalten manuell für sie zu arbeiten.

Das ist für mich gelöst (Kreuz pjsip für ARM Kompilieren):

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