Error in xcode project: ld: library not found for

Question

Just upgraded to Snow Leopard, installed Xcode 3.2, then installed iPhone SDK 3 for SL.

In a project, I now get the following error on build:

ld: library not found for -lcrt1.10.6.o

I've searched around the net, but nothing helpful can be found.

Answer 1

Setting deployment target to compiler defaults solved the problem. Don't change anything else.

Answer 2

I had this problem when I was using Xcode 4 on one machine and Xcode 3.2.6 on another. The two versions are supposed to be able to swap .xcodeproj files between them but I found that in the project.pbxproj file (inside the .xcodeproj directory), there were still a couple of places that read:

MACOSX_DEPLOYMENT_TARGET = 10.6;

I quit Xcode and went and changed the three occurrences to:

MACOSX_DEPLOYMENT_TARGET = 10.5;

After reopening the project, I could build again. Whew!

Answer 3

The compiler normally uses crt1.o combined with crt[i/n].o and crt[begin/end].o to support the constructors and destructors (functions called before and after main and exit).

This error could be caused by this missing library file for the specific deployment target.

First, do some investigation, like:

1. List all your deployment targets:

   ls -la /Developer/SDKs
   

2. Find which crt1 libraries do you have for which environment

   find /Developer/SDKs -name crt1\*
   

   You could see something like:

   /Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.10.5.o
   /Developer/SDKs/MacOSX10.5.sdk/usr/lib/crt1.o
   /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.5.o
   /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o
   /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.o
   

As you can see in above example, crt1.10.6.o is missing for MacOSX10.5.

Solution 1

You can solve that by creating the link to the missing file pointed to the other environment, or you could change your deployment target. E.g.

ln -s /Developer/SDKs/MacOSX10.6.sdk/usr/lib/crt1.10.6.o /Developer/SDKs/MacOSX10.5.sdk/usr/lib/

---

Other reason why it's missing, is that you could have different gcc installed in your system. E.g.:

which gcc
xcrun -find gcc
brew list | grep gcc; brew list gcc47

Solution 2

So when you're compiling using make, you can actually specify the right compiler by CC variable. E.g.

CC=/path/to/gcc-3.4 make

---

Solution 3

What you can also try is specifying the right target deployment environment variable for gcc, e.g.:

export MACOSX_DEPLOYMENT_TARGET=10.5

If this works, then you can add this library path to your shell profile (~/.profile). E.g.

export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include

export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib

Or by temporary exporting them.

---

How to test

Create the example conftest.c file with the following code:

#ifdef __GNUC__
  yes;
#endif

And try to compile it via:

gcc conftest.c
cc conftest.c
cc conftest.cc conftest.c

Answer 4

Wasted few hours on this one...

Interestingly, for me the problem was only for Simulator-Debug. It wasnt complaining for Simulator-Release or Device Debug/Release!

anyway, Changing Deployment Target to 10.5 solved this for me!!

Answer 5

I had the same error message, none of the above solutions worked for me. I resolved it by deleting the *.pbxuser and *.mode1v3 files inside the xcodeproj file.

1. Control/click the xcode *.xcodeproj file
2. Select the "show package contents" option from the menu
3. A window will open with the contents
4. Delete the pbxuser/mode1v3 files that start with your user name
5. Rebuild the project

Answer 6

Add the following to ~/.profile (for Mac OS X 10.5):

export C_INCLUDE_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/include

export LIBRARY_PATH=/Developer/SDKs/MacOSX10.5.sdk/usr/lib

Given Kirandan's limited scenario (Snow Leopard, Xcode 3.2.1, iphone, library path error), Stefan's answer (above) worked for me, except my exception was with 10.5 (-lcrt1.10.5.o).

Elsewhere, I'd seen an answer by Gabor Cselle (author of reMail), and he fixed this specific issue by using a symbolic link (someone referenced this page, by the way), but he noted this was not the best way.