Brak pliku crti.o

Question

Buduję projekt za pomocą łańcucha narzędzi GNU i wszystko działa poprawnie, dopóki nie dojdę do połączenia, gdzie linker skarży się, że go brakuje/nie może znaleźć crti.o. To nie jest jeden z moich plików obiektowych, wydaje się być związany z libc, ale nie mogę zrozumieć, dlaczego potrzebowałby tego crti.o, czy nie użyłby pliku biblioteki, np. libc.a?

Jestem cross kompilacji dla platformy ramię. Mam plik w toolchain, ale jak mogę go dodać do linkera?

crti.o znajduje się na jednej ze ścieżek wyszukiwania bibliotek, ale czy powinien szukać pliku .o na ścieżce biblioteki?

Czy ścieżka wyszukiwania jest taka sama dla gcc i ld?

Answer 1

crti.o jest biblioteką bootstrap, zazwyczaj dość małą. Zwykle jest on statycznie połączony z twoim plikiem binarnym. Powinien znaleźć się w /usr/lib.

Jeśli używasz dystrybucji binarnej, mają tendencję do umieszczania wszystkich pakietów programistycznych w pakietach -dev (np. Libc6-dev), ponieważ nie jest to konieczne do uruchamiania skompilowanych programów, tylko po to, aby je skompilować.

Nie kompilujesz się wzajemnie, prawda?

Jeśli kompilujesz skrosowanie, zwykle jest to problem związany z tym, że ścieżka wyszukiwania gcc nie pasuje do miejsca, w którym znajduje się plik crti.o. Powinien zostać zbudowany, kiedy był toolchain. Pierwszą rzeczą do sprawdzenia jest gcc -print-search-dirs i zobacz czy crti.o znajduje się na którejkolwiek z tych ścieżek.

Łączenie jest faktycznie wykonywane przez ld, ale ma ścieżki przekazane do niego przez gcc. Prawdopodobnie najszybszym sposobem, aby dowiedzieć się, co się dzieje jest skompilowanie programu helloworld.c i obejrzenie go, aby zobaczyć, co jest przekazywane do ld i zobaczyć, co się dzieje.

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

otworzyć plik dziennika i szukać crti.o, jak widać mój non-cross kompilator:

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 

Jeśli pojawi się kilka prób open(...crti.o) = -1 ENOENT, ld jest uzyskiwanie mylić i chcesz zobaczyć, gdzie otworzyła się ścieżka, którą otworzył ...

Answer 2

Ten sam problem pojawia się na domyślnej instalacji Ubuntu 8.04. Musiałem ręcznie pobrać nagłówki/pliki programisty libc, aby działał.

Answer 3

OK Musiałem ponownie zainstalować łańcuch narzędzi, aby następnie brakujące pliki zostały uwzględnione. Wydaje się dziwne, ponieważ powinien znaleźć go na ścieżce gcc. Głównym problemem wydaje mi się, że miałem 15 różnych plików crti.o na moim komputerze i nie wskazywałem na poprawny. Nadal nie działa od teraz, ale działa teraz :-) Dzięki za pomoc :-)

Answer 4

Miałem podobny problem z źle ustawionym cross-kompilatorem. Mam wokół niego tak:

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

Zakłada/lib,/usr/include i tak dalej istnieć w miejscu wskazanym przez opcję sysroot. Prawdopodobnie nie jest tak, jak powinno się robić, ale wyciągnęło mnie to z kłopotów, gdy potrzebowałem skompilować prosty plik C.

Answer 5

to rozwiązane dla mnie (cross kompilacji PJSIP dla ARM):

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

Answer 6

miałem ten sam problem przy jednoczesnym cross-kompilacji. crti.o był w <sysroot>/usr/lib64, ale linker go nie znalazł.

Okazuje się, że tworzenie pustego katalogu <sysroot>/usr/lib naprawił problem. Wydaje się, że łącznik będzie szukać ścieżką <sysroot>/usr/lib pierwszy, i tylko wtedy, gdy istnieje byłoby nawet rozważyć <sysroot>/usr/lib64.

Czy to błąd w linkerze? Czy to zachowanie jest gdzieś udokumentowane?

Answer 7

W moim przypadku Linux Mint 18.0/Ubuntu 16.04 nie mam crti.o w ogóle:

$ find /usr/ -name crti* 

znajdę nic więc zainstalować pakiet programu:

sudo apt-get install libc6-dev 

Jeśli znajdziesz jakieś libs read here