views:

1755

answers:

3

Hey,

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 ??

A solution and explanation would be great :-)

Thanks, Richard

I'm cross compiling for the arm platform. I have the file in the tool chain, 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?

and is the search path the same for gcc and ld?

+1  A: 

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 your 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.

Your not cross-compiling are you?

If your 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 tool chain 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 it's paths passed down to it by gcc. Probably the quickest way to find out whats going on is compile a helloworld.c program and strace it to see what is getting passed to ld and see whats going on.

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

Open the log file and search of 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...

stsquad
yes I'm cross compiling for the arm platform. I have the file in the tool chain, but how do I get the linker to include it?Thanks!
Richard
yes crti.o is on one of the 'libraries' search path, but should it look for .o file on the library path?
Richard
and is the search path the same for gcc and ld?
Richard
A: 

I get the same kind of issue on a default Ubuntu 8.04 install. I had to get the libc developer headers/files manually for it to work.

leppie
+1  A: 

OK I had to reinstall the tool chain, so that the missing files were then included. It seems strange since it should have found it on the gcc path. The main problem I guess was that I had 15 or so different crti.o files on my computer and wasn't point to the correct one. Still doesn't make since but it works now :-) Thanks for your help :-)

Richard