Crti.o missing file

Question

I am building a project using the GNU toolchain, and everything works fine until I contact him, where the linker complains that he is missing / cannot find crti.o This is not one of my object files, it seems to be related to libc, but I can’t understand why it needs crti.o , whether it will use a library file, for example. libc.a ?

I use cross-compilation for the hand platform. I have a file in the toolchain, but how do I get the linker to enable it?

crti.o is in one of the library search paths, but should it search for the .o file on the library path?

Is the search path the same for gcc and ld ?

Answer 1

crti.o is a bootstrap library, usually quite small. It is usually statically linked to your binary. It should be found in /usr/lib .

If you use a binary distribution, they usually put all of the developer’s materials in -dev packages (for example, libc6-dev), since you do not need to run compiled programs, just to create them.

You're not cross-compiling, are you?

If you are doing cross-compilation, usually the problem with the gcc search path does not match your crti.o. It had to be built when there was an instrumental chain. The first thing to check is gcc -print-search-dirs and see if crti.o is in any of these paths.

The binding is actually done using ld, but it has its own paths passed to it by gcc. Probably the fastest way to find out what's going on is to compile the helloworld.c program and compile it to see what ld is being transmitted and see what happens.

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

Open the log file and search for crti.o, as you can see my non-cross-compiler:

 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 

If you see a bunch of attempts open(...crti.o) = -1 ENOENT , ld gets confused, and you want to see where the path came from, from which it opens ...

Answer 2

I had the same issue when cross compiling. crti.o was in <sysroot> / usr / lib64 , but the linker did not find it.

It turns out that creating an empty <sysroot> / usr / lib directory fixes the problem. It seems that the linker first looks for the path <sysroot> / usr / lib , and only if it exists does it even consider <sysroot> / usr / lib64 .

Is this a bug in the linker? Or is this behavior recorded somewhere?

Answer 3

OK I had to reinstall the tool chain to then include the missing files. Seems odd as he should have found him on the gcc path. The main problem, I think, is that I had 15 or so different crti.o files on my computer and did not point to the correct one. Since then it does not work, but now it works :-) Thanks for your help :-)

Answer 4

I had a similar problem with a poorly configured cross-compiler. I went around it like this:

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

This assumes / lib, / usr / include, etc. exist at the location pointed to by the sysroot option. This is probably not the way it should be done, but it saved me the trouble when I needed to compile a simple C file.

Answer 5

In my case, Linux Mint 18.0/Ubuntu 16.04 I don't have crti.o at all:

 $ find /usr/ -name crti* 

I find nothing, so I install the developer package:

 sudo apt-get install libc6-dev 

If you find several libs here, read here.

Answer 6

I get the same problem when installing Ubuntu 8.04 by default. I had to get libc developer files / files manually for it to work.

Answer 7

This solution is for me (cross-compiling pjsip for ARM):

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