How can I build an older gcc (specifically, 4.5.2) on Ubuntu 11.10 and avoid errors about "/usr/bin/ld: cannot find crti.o: No such file or directory"?

I've done a bit of digging and found several similar items, but none that actually resolve my issue:

  • I've verified all my packages (libc6-dev and the like) are re-installed per this question
  • I've verified crti.o exists in /usr/lib32 and /usr/lib/x86_64-linux-gnu, and that my ld.so.conf is configured to look in those directories
  • I've verified that prepending my make invocation with LIBRARY_PATH=/usr/lib/x86_64-linux-gnu works, but would like to avoid this (it becomes a diverging point in makefiles)
  • I've tried various things with --with-build-sysroot, but with no success (read: maybe I just don't know the right flag to set)
  • When running with strace (as per this answer), I can see the bare reference to crti.o:

    13240 open("crti.o", O_RDONLY) = -1 ENOENT (No such file or directory)


4 Answers 4


Even very new versions of GCC fail with that message. It's because the new Debian/Ubuntu releases (will) support multiarch (i.e. installing binaries for multiple machines in one file-system), so the libraries have been moved away from the standard places.

There are GCC patches to fix it here (not yet approved final versions, but correct for Ubuntu), and they probably apply to older GCC without much effort, maybe. I think you need to configure GCC with --enable-multiarch, or something.

In the meantime, creating soft links is a good fixup:

cd /usr/lib
ln -s x86_64-linux-gnu/crt*.o .

(the folder name will be different on 32-bit installations).

Hope that helps.

  • Thanks for the point about it being multiarch. I was hoping for resolution on "why" it stopped working.
    – Matt
    Nov 14, 2011 at 18:37

I had the same problem. Making symbolic links from /usr/libs/crt?.o to /usr/lib/x86_64-linux-gnu/crt?.o solved the problem for me.

  • This does work, yes. I was hoping for a solution that was more along the lines of tweaking the gcc installation rather than mucking with underlying file structures, though...
    – Matt
    Nov 9, 2011 at 18:21
  • I wanted to add that in my case, I recompiled glibc and GCC, but I forgot to get rid of an older slackware-gcc variant that was at /usr/bin/. When I removed the latter, I could compile certain things again (such as gcc again).
    – shevy
    Nov 14, 2018 at 6:05

I solved this problem with a couple of workarounds that might be useful for you.

First, build GCC with LIBRARY_PATH=/usr/lib/x86_64-linux-gnu, so that the build bootstrap process knows where to find the crt?.o start files.

Then, instead of making crt?.o symlinks in /usr/lib where they affect your whole system, you can symlink those three files into the ${prefix}/lib/gcc/... directory corresponding to the ${prefix}/bin directory that the gcc executable is installed in. That's actually almost at the top of its search path for the start files, so it will find them -- but they don't affect anything else.

In my case, the specific directory to put them in was lib/gcc/x86_64-unknown-linux-gnu/4.3.2/; you can find the right one because it already has other files like crtbegin.o in it.


I built GCC 4.1.2 on Ubuntu precise x86_64. As you did, I took a look at the strace of last command "xgcc" looking for 32bit c runtime, grep-ped /32/ as follows. C runtime in mine is in /usr/lib32 which is provided by libc6-dev-i386 package.

fgrep /32/ strace-output.txt | grep /usr/lib | head -1
access("/usr/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/32/crti.o", R_OK) = -1 ENOENT (No such file or directory)

So, I created the crt?.o symlinks in the directory xgcc looked for.

sudo mkdir -p /usr/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/32
cd /usr/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/32
sudo ln -s /usr/lib32/crt1.o 
sudo ln -s /usr/lib32/crtn.o 
sudo ln -s /usr/lib32/crti.o 

I successfully built GCC 4.1.2 with it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .