When I switch the Compiler Version to Clang llvm 1.0 in existing projects I get the following build error when Precompiling the *.pch file:
error: can't exec '/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc-4.2' (No such file or directory)
Is there another setting I need to change to get my project to work with the new compiler?
(I did try a clean all targets)
Update:
To clarify:
Since the new compiler does in fact work with new projects, the issue is not that my system is missing anything.
Additionally, Xcode should not even be trying to find llvm-gcc-4.2 as the whole point is that I switched from that compiler to the new one, Clang llvm 1.0. This is what has led me to believe there is still another setting to be changed.
Thanks to fbereto for his suggestion. The actual answer lies in the comments.
If you look in path specified by the error you will not find an LLVM compiler (llvm-gcc-4.2) for the iPhone device:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/
That being said one does exist for the iPhone Simulator:
/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/
All this to say that while it may be possible to compile your iPhone App under LLVM for the Simulator, no equivalent tool exists for the device itself.
(Answer detailed in comments below.)
Related
Not true for all new iOS 5 methods but I've found out that calling UINavigationBar's setBackgroundImage:forBarMetrics: method will trigger an 'instance method not found' warning if the deployment target is under 5.0. This is even though I am linking with the SDK 5.0.
More importantly the enum UIBarMetrics used as a parameter there is reported as an 'undeclared identifier' and this will trigger a compiler error.
Any idea why this is so? I realized the code will not work if the deployment target is under 5.0 but I'm checking if UINavigationBar responds to that selector at run time, so everything should be ok. I don't understand the compiler error though.
EDIT:
This only happens when compiling for a device, and when a device is actually plugged in (the device I've tested with runs iOS 5.0.1).
Well, I figured out the mystery. I manage to fix the problem by deleting SDK 4.3 (I had that one copied over from Xcode 3 since it doesn't come by default with the latest Xcode+SDK package and I was using it for another legacy project).
I still can't explain why having both SDKs caused the error since I was clearly compiling with the latest SDK.
I've been compiling and using the following code since iOS 4.0:
if(UIGraphicsBeginImageContextWithOptions != NULL)
{
UIGraphicsBeginImageContextWithOptions(drawCopyFS.frame.size, NO, 0.0);
}
else
{
UIGraphicsBeginImageContext(drawCopyFS.frame.size);
}
As soon as I switched to 4.3 SDK, this particular piece of code stopped compiling with the following two errors:
'UIGraphicsBeginImageContextWithOptions' undeclared (error on line #1)
Implicit declaration of function 'UIGraphicsBeginImageContextWithOptions' (error on line #7)
Anyone have any ideas why this is happening? Is something changed in 4.3, or how can I fix this?
Xcode doesn't color UIGraphicsBeginImageContextWithOptions the same way as it does UIGraphicsBeginImageContext and at the same time it doesn't provide any quick help for it.
First make sure the Base SDK is set to use the latest in the Project Info. If that doesn't work then read on.
I had a similar problem with UIBackgroundTaskIdentifier which was introduced in 4.0 and compiled fine before the SDK update. It turned out that Xcode was attempting to use headers from the iOS 3.2 SDK. The console output of the build process showed the old headers search path was passed into the compiler even though the Base SDK was most definitely set to the lastest in the Project Info.
Reloading the project didn't help. Restarting Xcode had no effect. There are reports that manually editing the project file has been necessary with past updates. However, when I opened the project file in a text editor I found the SDKROOT variables were correctly set to the latest SDK path.
What worked in my case was closing Xcode, restoring the 'MyProject.xcodeproj/project.pbxproj' file from source control to a point just prior to updating the SDK, then restarting Xcode and opening the project.
I was having the same problem with that symbol and also a bunch of other symbols, selectors and macros. As with the other responder, cleaning everything and removing pre-compiled headers didn't fix it. Nor did changing the SDK. What did fix it is switching from a simulator build to a device build, and then switching back.
I have been able to run the Static Analyzer on my code fine for months. All of a sudden now I am getting the error:
<command line>:0:0 Analyzer skipped this file due to parse errors
Not sure how to diagnose.
The first tile it skips is:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.1.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGPDFContext.h:0:0 Analyzer skipped this file due to parse errors
I get these errors too if I try to use it when the target is set to the simulator, but if I switch the target to the device then it works.
Typically, this is a result of a syntax error or something else that is preventing your code from compiling.
Because you are only seeing errors when you go to analyze your code, not when it compiles, I bet that you are using the GCC compiler for your main application builds. Clang / LLVM has a bug in the iOS 4.1 SDK that causes compilation errors when targeting the Simulator, but not the device. The Clang Static Analyzer is probably exhibiting this same bug.
The solution I provide in my answer to the above-linked question should work to fix this as well. However, it may lead to compilation errors when you switch back to build your application with GCC, so I recommend switching your compiler over to LLVM. Unless you are using C++ code, I recommend using LLVM for iPhone projects anyway, due to the minor performance boosts you can get in your compiled application with it.
I'm still pretty new at iPhone development and I'm running into this odd build error which I do not understand. I'm trying to build and run my iPhone application and XCode is telling me that it can not find NSPredicate. To my understanding it was made available in iPhone SDK 3.0 and I'm trying to build for 3.1. I set the target to being "Simulator - 3.1.2 | Debug" in the top left selection box and then hit "Build and Go". I tried setting it in the target app's info as well.
If anyone can direct me to where/what I can change or any documentation, I would appreciate it.
Thanks.
Have you built your project recently with an older version of the SDK. I have run into similar problems and I found that the first thing to do is to clean your target and then build again.
To clean your target open your targets group, right click or control+click on your target and select clean "_target_name_"
Hope this helps.
NSPredicate is part of the Foundation so if you can't find that something is badly scrambled.
(1) Check for circular imports in the headers. These can cause all kinds of weird problems.
(2) Remove all frameworks, clean all, then add the frameworks back in in order. Make sure the target is set for 3.x.
In the past, when I've hit a build problem like this, I found it easier to create a new project and move my custom source to it than to try to figure out what I screwed up on the original. Life's to short to debug a linker.
I have received many errors while trying to Build & Run my iphone app using the xcode.
All the errors stated "non lazy ptr" for the used variables in the code.
The solution for me (and for all of you) is to look for the correct framework to be used according to the Simulator and Device versions the code will be running on.
At first i have chosen the AVFoundation framework from the iphone os 2.2 folder. and when i removed that and choose the framework from the iphone os 3.0 folder - the linking errors where gone and the code run perfectly.
so, in short the solution is to change the framework source folder.
Hope that helps :)
Frameworks should automatically be taken from the Active SDK, so resetting them shouldn't be necessary. We've seen some projects that have somehow gotten hardcoded SDK paths into their Framework Search Paths build settings; that is often the cause of this problem (and your fix simply hardcodes a more-recent path for an invalid one, which kicks the can down the road a ways but will break again in the next SDK bump.) The real solution is to look at your target's Framework Search Paths and delete any SDK-specific paths you find.