I have been able to Archive on Xcode 4 successfully, but all of a sudden (??), I can't. The build fails with an invalid .pch file. The error is pasted in below (got from a reattempt with -Winvalid-pch, but what seems to be happening from the build log is that the precompiled header is not actually getting precompiled-- it's an iOS app, and goes straight from a CopyPNG step to a .m compile.
Could I have flipped something by accident? Nothing seems odd in my diff of the .pbxproj file.
cc1obj: warning: /Users/myname/Library/Developer/Xcode/DerivedData/Foo-afikuaovoaeqhreaaaakpafseuuv/Build/PrecompiledHeaders/Foo_Prefix-guqixmujoiaaaacwjctfkrztxmbz/Foo_Prefix.pch.gch: created by a different GCC executable
cc1obj: error: /Users/myname/Library/Developer/Xcode/DerivedData/Foo-afikuaovoaeqhreaaaakpafseuuv/Build/PrecompiledHeaders/Foo_Prefix-guqixmujoiaaaacwjctfkrztxmbz/Foo_Prefix.pch: No such file or directory
cc1obj: error: one or more PCH files were found, but they were invalid
The "Precompile Prefix Header" build setting is "Yes" for all configurations. Product->Clean doesn't help. Deleting the cached pch stuff under derived data doesn't fix it. Really seems like the whole "precompile" step is missing.
Another factoid: Enabling the setting "Increase Sharing of Precompiled Headers" DOES let it succeed. But I can find almost no reference to what this flag really does, and I have never used it before. And perhaps reasonably, the precompile step still doesn't show up when this happens.
Have you cleaned and then rebuilt? Product Menu ==> Clean. Cleaning usually solves such problems, effectively instructing Xcode to compile everything, regardless of whether it thinks the previous build of that file is still valid.
If that fails, try wiping out the Derived Data folder for the project, at ~/Library/Developer/Xcode/DerivedData/YourProjectNamexxx where xxx is a uuid-style string.
The approved answer is correct, just a note that it works only in some cases.
I just converted a project into workspace and changed Derived Data Location from default to Workspace-relative. Precompiled headers stopped working immediately and cleaning the old location didn't seem to make any difference. Well of cource, since it was the OLD location!
Workspace relative location seems to located inside folder, where the workspace file (myProject.xcworkspace) was saved. There's now new subfolder DerivedData, which contains folder named by workspace, which contains the familiar stuff.
Index folder contains the PrecompiledHeaders, which contains (finally) the several subfolders. Deleting all of those and recompiling forced precompiling happen.
Related
I created a project, lets say named AddonLib, which is part of a big solution. For some unknown reason, the folder where the source code was put was named AddonLib_1. I've been trying to get rid of that "_1" for too long now and is driving me crazy. Things I've tried:
removed the project, from TFS and the solution. Renamed the directory. When I try to add the project again, I get the message "The project file "blabla\AddonLib_1\AddonLib.vcxproj" has been moved, renamed or is not on your computer".
Edited the xml file of the solution. Check the project file just to be sure. Removed any trace of the project with and without _1. The project AddonLib is no longer part of the solution. Try to add it back again, same error as before.
Cleared the VS cache following the instructions here. Repeated previous step. Same error.
I cannot find any reference to AddonLib_1 on my code, xml files, anything. But everytime I try to load the project, I get the same error.
Looking for the string "AddonLib_1" using findstr gives no results...
This causes the build to break. Even if there are no references (that I can find) to AddonLib_1, when building in the server I get an error "project AddonLib_1/AddonLib.vcxproj could not be found blablabla"....
Besides the solution xml file, the project xml file, the xml files of the few projects that depend on this project, where else can the information that once the project was in the directory AddonLib_1 ?
More info:
I can remove the project. Remove it from TFS, from the solution, and delete the directory. Create a new project with the desired name. Add the source and header files. Now, I need to add some info to the project xml file. If I open the xml file and edit, when I try to load back the project (Which was loaded before!) I get the same error message. If I open the xml again, undo the minor change I did, I still get the error. Again, this is in a new project, starting from zero.
I was able to solve this issue by removing the .suo file as described in this apparently unrelated answer
I recently had to move my project to a different folder, and now when I run for some reason when I create the NSManagedSubclasses it seems to be making two copies. One in the correct location I tell it to save and another in Library->Developer->Xcode->DerivedData->WorkOrders-eamzgsjrwlhqoohhbyqilrvnbskh->Build->Intermediates->Workorders.build->Debug-iphoneos->WorkOrders.build->DerivedData->CoreDataGenereated->Workorders-> (NSSubclassed files here)
My problem is it won't compile now with the error below.
<unknown>:0: error: filename "Uploads+CoreDataClass.swift" used twice: '/Users/josephastrahan/Documents/Distribution.Tech/Work_Orders_iPhone/WorkOrders/Uploads+CoreDataClass.swift' and '/Users/josephastrahan/Library/Developer/Xcode/DerivedData/WorkOrders-eamzgsjrwlhqoohhbyqilrvnbskh/Build/Intermediates/WorkOrders.build/Debug-iphoneos/WorkOrders.build/DerivedSources/CoreDataGenerated/WorkOrders/Uploads+CoreDataClass.swift'
<unknown>:0: note: filenames are used to distinguish private declarations with the same name
<unknown>:0: error: filename "Uploads+CoreDataProperties.swift" used twice: '/Users/josephastrahan/Documents/Distribution.Tech/Work_Orders_iPhone/WorkOrders/Uploads+CoreDataProperties.swift' and '/Users/josephastrahan/Library/Developer/Xcode/DerivedData/WorkOrders-eamzgsjrwlhqoohhbyqilrvnbskh/Build/Intermediates/WorkOrders.build/Debug-iphoneos/WorkOrders.build/DerivedSources/CoreDataGenerated/WorkOrders/Uploads+CoreDataProperties.swift'
<unknown>:0: note: filenames are used to distinguish private declarations with the same name
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1
For some reason it thinks the same file is being declared twice, very bizarre and not sure how to fix this. I looked at other answers here (How to resolve error showing like filename used twice), but none of the answers solved my issue.
Note:: Also, If I delete the files they just come right back in the derivedData location you see in the attached image upon recompilation.
Even stranger, I was doing some tests, and I created only the workorder object but not the upload object and it compiles fine! I look in my build phases and don't see upload anywhere even though workorder has a relationship to it in code! It must be accessing the file from that derivedLocation for some reason.
Any help why is appreciated.
I think I found the solution but not sure why, so anyone that can elaborate would be appreciative.
I was reading a post here (XCode 8 generates broken NSManagedObject subclasses for iOS 10), and after reading the answer by Ryan H. I figured to give it a try.
By setting the codegen option to manual and setting the global space to my current project (see attached image), I deleted the files in the derived location and now they don't reappear and I don't get the duplicate error and everything compiles. I'm not sure how the codegen option even changed in the firstplace but something to watch out for sure.
So I'm trying to adapt a file maker plugin to work on a Mac with xcode. There is code already written and compiled for the plugin but we need to update because a lot of internal changes have been made. I open the project in xcode and hit build and I'm given something like 135 errors saying that these files don't exist (e.g. "error: FMWrapper/FMXExtern.h: No such file or directory"). The issue is I'm looking at these files right now, they certainly exist, it's just that they aren't getting read. I've moved them through the project to nearly every file and I still get the same error. The lines that are causing the errors are as such:
#include "FMWrapper/FMXExtern.h"
And so on...
Any suggestions?
The compiler won't scan your whole hard disk for included files recursively (unless you ask it to -- but don't! :). You need to help it out. Otherwise, your builds would take ages.
One way is to specify the path to these sources using the Xcode build setting HEADER_SEARCH_PATHS or USER_HEADER_SEARCH_PATHS.
So you tell Xcode to add the directory that contains FMWrapper/ to the search paths.
Xcode Build Setting Reference
When you add a source file to the Compiled Sources section of a target's Build Phase it describes the location of each file in light gray next to the files:
...in ../../shared_source/controllers
How is Xcode create this string? I'm having trouble with a project that gets it "wrong" -- seems to be a directory relative to someone else's environment, but not mine. Removing and re-adding the source does not help, nor does any amount of cleaning.
When you're adding the source to your project, do you check the "copy items into destination group's folder" option? If you don't, XCode is just pulling a reference from wherever the file is, without actually copying it into the project. This works fine until the original file gets moved. In my experience you generally want to copy.
I am trying to set up Xcode for a project which contains multiple executables and static libraries. I have created multiple targets and set up the linking and dependencies, and initially everything works great. The catch...
This is an existing project which already has Visual Studio and Makefile builds. Those builds put the libraries in a lib/Debug directory and the executables in bin/Debug. So in Xcode I changed the Build Products Path to "lib" and "bin" respectively (so we can use one set of documentation for all of the platforms). This puts the compiled targets in the right place, but completely breaks both the linking (Library not found) and the dependencies.
I can fix the linking by adding $(SRCROOT)/lib/Debug to the Library Search Paths for each executable (but it feels like Xcode should be able to figure this out on its own, which makes me think I'm doing something wrong).
But — I can't figure out how to get the dependencies working again. If I change a library source file, the library will rebuild but not the dependent executables. If I force a build of the executable Xcode returns success without doing anything; it thinks the target is up to date. If I clean the target and then rebuild it works.
So, any ideas here? Is Xcode being fundamentally stupid in this regard, or is it me (I'm leaning toward the latter)?
Update: I've posted a sample project to demonstrate the issue at http://share.industriousone.com/XcodeDepsIssue.zip. Build it once, then modify MyStaticLib.c and build it again. The executable will not relink (and it should). Many thanks for any help on this one.
starkos, thanks for publishing your conclusion. It validated my experience as well. This situation really screwed me, so it was nice to know I wasn't just missing something.
I did however discover a workaround that avoids creating multiple projects or keeping the library and its dependent in the same directory. It is a hack, but it does work here.
I know it's a bit late but better than never.
For the dependency library, add a "Copy Files Build Phase", with Absolute Path as the destination, and the path text field should be the directory where the DEPENDENT target lives. Then click on Products, find the dependency library (will end with .a), and drag it into the "Copy Files Build Phase." If you now build, this will put the library into its own directory like before and THEN also copy it into the dependent's target directory.
For the dependent, you can now remove the dependency's output directory from the Library Search Paths. This will cause it to find the library copy. If you do this, the dependent will indeed be relinked each time the dependency .a is relinked.
The negatives are, of course, the extra time for the copy, and the necessity to specify (in the Copy phase) the target directory for each dependent of your library. Beats the hell out of the alternatives though....
Xcode doesn't automatically set up dependencies based on use of build products; you have to set up explicit target dependencies yourself.
Project > Edit Target Settings, General tab, + button, add any targets that are prerequisites to building the selected target. That should get you going again.
I've researched this some more and the answer is no, Xcode 3.x doesn't track dependencies between targets that live in different directories. You can work around it by giving each library its own project, and adding each of those to a master project. Or you can keep all of your targets in one directory. Pick your poison.
Here is my solution for this weird behavior in xcode 4.3.1. You have to add build pre-action in scheme:
rm -f ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
and choose which build settings to use for this script. Each time before build, target executable will be removed and rebuild completely. It helped for me, and i hope it helps you.
NOTE: Have tried to put this script in project build phase, and result was negative - debugger could not connect process to start debugging.
Good luck!
OK, it would help to have the text of the Linking... build line that's failing. But a couple of things:
1) You shouldn't be linking to anything in $(SRCROOT). That's your project sources. The two places to find things to link are $(SYMROOT) (the Build Products directory) or $(DSTROOT) (the Installed Products directory).
One thing you could do is to have a common Build Directory, then use 'xcodebuild install' action to install the products in the Installation Directory. The other is to use a Copy Files build phase to copy them after building, so you can link against them in $(SYMROOT) but still have them where your Windows compatriots expect them.
THere is probably a way to set up the per-target build products directories correctly, but I'd really have to see the project itself to figure it out.