Question

I’m building a project using a GNU tool chain and everything works fine until I get to linking it, where the linker complains that it is missing/can’t 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 would need this crti.o, wouldn’t it use a library file, e.g. libc.a?

I’m cross compiling for the arm platform. I have the file in the toolchain, but how do I get the linker to include it?

crti.o is on one of the ‘libraries’ search path, but should it look for .o file on the library path?

Is the search path the same for gcc and ld?

Answer 1

crti.o is the bootstrap library, generally quite small. It’s usually statically linked into your binary. It should be found in /usr/lib.

If you’re running a binary distribution they tend to put all the developer stuff into -dev packages (e.g. libc6-dev) as it’s not needed to run compiled programs, just to build them.

You’re not cross-compiling are you?

If you’re cross-compiling it’s usually a problem with gcc’s search path not matching where your crti.o is. It should have been built when the toolchain was. The first thing to check is gcc -print-search-dirs and see if crti.o is in any of those paths.

The linking is actually done by ld but it has its paths passed down to it by gcc. Probably the quickest way to find out what’s going on is compile a helloworld.c program and strace it to see what is getting passed to ld and see what’s going on.

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 to open(...crti.o) = -1 ENOENT, ld is getting confused and you want to see where the path it’s opening came from…