crti.o file missing

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?

Dakota

For Mac, see: stackoverflow.com/questions/1365211/… stackoverflow.com/questions/10941247/… – Antipyrine

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

Remora

+1 for the immensely useful strace trick. But my issue still remains unresolved (cross compiling pjsip on ARM) – Bohunk

@Bohunk it might be a different issue. Can you post a question with the output your getting? – Remora

@Remora It is the same issue of misconfiguration toolchain. I have found a solution that fixes the problem for me. See my answer below. – Bohunk

Answer 2

I had the same issue while cross-compiling. crti.o was in <sysroot>/usr/lib64 but the linker would not find it.

Turns out that creating an empty directory <sysroot>/usr/lib fixed the issue. It seems that the linker would search for a path <sysroot>/usr/lib first, and only if it exists it would even consider <sysroot>/usr/lib64.

Is this a bug in the linker? Or is this behaviour documented somewhere?

Newburg

This worked for me. I dread to think how much messing around you had to go through to discover that. No idea whether this is a bug or what - but perhaps worth taking up on the GNU ld bugzilla or mailing list or something. – Kiloton

Answer 3

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

$ find /usr/ -name crti*

I find nothing so I install developer package:

sudo apt-get install libc6-dev

If you find some libs read here

Oira

Answer 4

If you are cross-compiling , add sysroot option in LDFLAGS

export LDFLAGS=""--sysroot=${SDKTARGETSYSROOT}" -L${SDKTARGETSYSROOT}/lib -L${SDKTARGETSYSROOT}/usr/lib -L${SDKTARGETSYSROOT}/usr/lib/arm-poky-linux-gnueabi/5.3.0"

Mother

in cross compiling setting sysroot is crucial. Just setting sysroot in compiler is not enough, as @surajit declared one must also configure in linker setting. In some IDEs it is done in "Miscellaneous" menu. – Coranto

Answer 5

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 :-)

Dakota

Answer 6

I had a similar problem with a badly set-up cross-compiler. I got around it like so:

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

This assumes /lib, /usr/include and so on exist in the location pointed to by the sysroot option. This is probably not how things are supposed to be done, but it got me out of trouble when I needed to compile a simple C file.

Prader

Answer 7

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.

Unmoved

Answer 8

This solved for me (cross compiling pjsip for ARM):

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

Bohunk

Answer 9

In addition to all the other answers here (and the good advice by @stsquad (https://mcmap.net/q/15909/-crti-o-file-missing), consider also the possibility that development tools have been upgraded and paths have changed but, in specific development projects, automake-generated files are stale, looking at the previous development tools paths. In which case try and bootstrap again automake-generated files.

If there is no bootstrap script, perhaps this can do the job:

aclocal \
&& automake --gnu --add-missing \
&& autoconf --verbose --force --warnings=all \
&& autoupdate \
&& libtoolize -c -f -i \
&& autoreconf --install --symlink --force

Diatomaceous