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.
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.
It looks like you're picking up libraries from /usr/lib, which is wholly inappropriate for the iPhone SDK. I would assume you've changed your build settings to add /usr/lib to the library search paths. This should be completely unnecessary in the first place, as /usr/lib is in the compiler's standard search paths, but if you need to have a modified search path like this, make sure to use $(SDKROOT)/usr/lib
instead.
Edit Project Settings -> In the build tab -> For Mac OS X Deployment Target, change it to 10.5 (not 10.6 even if on 10.6) and see if that helps.
P.S. Make sure you set that for all targets, not just release or debug. (if you didn't, one would fail, the other wouldn't)
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!!
I have (almost) the same issue. With Xcode 3.2 on Snow Leopard I try to build an app that worked fine on Leopard and Xcode 3.1 (it used to build both on the Simulator and the device).
First I got the error message
ld: library not found for -lcrt1.10.6.o
when the target was Simulator 3.1 Debug. So I changed the Mac OS X Target from "Compiler Default" to "OS X 10.5" and it builds and runs for Simulator 3.1 Debug.
However, if I try to build for "Device 3.1 Debug" or "Device 3.1 Release", I get the error message
ld: library not found for -lcrt1.10.5.o
I've been messing around in Xcode's Build settings for hours now, and whatever I try I just can't get it to compile on an OS3.1 device.
Ideas anyone?
I was able to fix this problem by adding the following to my Makefile:
CFLAGS="$(OTHER_CFLAGS) -mmacosx-version-min=10.5"
LDFLAGS="$(OTHER_LDFLAGS) -mmacosx-version-min=10.5"
Ostensibly, this is only required when building outside of Xcode. This problem frustrated me long enough that I figured it would be useful to share my experience here.
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
hi all, Trying to compile PhoneGapLibTest using XCode and keep getting error message:
library not found for -lSystemStubs
if I add the paths mentioned below to the projects lib and include search path i.e.
/Developer/SDKs/MacOSX10.5.sdk/usr/include
/Developer/SDKs/MacOSX10.5.sdk/usr/lib
I get thousand of errors?? Any ideas? Thanks greg
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
Stefan, thank you so much for your answer. I've no idea why your post has a -1, but given Kirandan's limited scenario (Snow Leopard, Xcode 3.2.1, iphone, library path error), I can vouch for your answer and say it is correct and works perfectly for almost this same scenario, except my exception was with 10.5 (-lcrt1.10.5.o). This fixed an issue I had compiling snort with gcc, which is included with XCode. So it may not work for everybody, however it should fix the issue with at least one other "answer" on this page, from "oohmygood", who is missing this same library, and thus I can perhaps understand at least 1 point, certainly not the -1, because of the general nature of the question, and Stefan's answer is as good as any on this page, where a library is not in your path.
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 - I think Stefan's solution is better and certainly fixed my issue.