There is an Objective-c framework in the project, the framework does not support running on simulator. It's not good for developing, so I excluded the file in Build Settings --> Excluded Source File Name, but this causes errors xxxx.h file not found. in Bridge-Header.h.
I also tried to set Validate workspace = yes, again, the framework seemed to be excluded, but it causes the errors.
How can I exclude framework correctly? and why the errors above happens?
Thanks.
This cause errors because Xcode can't find the files in the framework!You should find out all the files that have referred to any file of the framework. After you find them out, you'd better disable the functions provided by the framework, and remove all the reference in all the files. The errors will disappear after you remove all the reference
Don't delete or mess up the code, you need them when running on a real device after all.
Related
I just upgraded to Xcode 10, and I suddenly face this error when I try to build, any ideas how to fix it? I tried cleaning derived data, but without any luck.
If you use CocoaPods, click Xcode menu file -> Workspace Settings , And click Build system choice Legacy Build System
If you not use CocoaPods, same of top , select Project Settings
If your app is generating the error related to the multiple .app files just like mentioned above in question then removing the .plist files from "Copy bundle Resources" WILL NOT WORK.
If the error is related to .app file then follow the following steps.
Select the Target.
Go to Build Phases tab.
Remove the items listed in Output Files
Compile the code if it compiles successfully then not follow the next steps.
If code does not compile successfully and Xcode may give you an error related to "Library not found". Then add the missing library in General Tab in Linked Frameworks and Libraries that Xcode mentioned in the error.
Keep adding these libraries (that Xcode ask through compile errors) in Linked Frameworks and Libraries until the code compiles successfully.
Hope this helps.
You can try to change the build system to Legacy,
File > Workspace Settings > Build System > Legacy Build System.
I also faced this issue in xcode 10 but it was because of adding the same framework in main project + other extensions (watchkit or siri extension etc).
I added ObjectMapper in podfile for my main project + for my extensions. When I compiled it gave me an error that multiple command produce and also shows me which framework is causing this issue. Now its working fine for me as I've removed it from my extensions I wasn't using it in my extensions.
Don't know about your issue may be you can check your podfile.
If this is CoreData related. The issue is that you are trying to generate the NSManagedObject subclass but you need to set the 'CodeGen' option to Manual/None. This option is defaulted to Class definition and this would regenerate the code thus creating this issue.
i encountered this issue as well while working with CoreData.
in my .xcdatamodeld file, it came down to the fact that, during the creation of my various Entities, i had copy and pasted one multiple times (thinking i was saving time because various properties were similar enough that i thought this was a good idea).
the resulting Build error Xcode 10 - 'Multiple commands produce' occurred because i forgot to check and make sure the new Entities were set to their own unique corresponding class to match the new Entity in the Data Model Inspector pane.
unfortunately, it took me two days to figure out the original Entity's Class Name was still in place.
so lesson: careful when you copy/paste/duplicate Entities in CoreData.
(... i guess :0} )
some time saver. oops! hope this helps someone.
I had this same issue with Core Data entity class. I had forgotten to select Codegen Manual / None because I do not allow mine to be autogenerated. So I had a class in place and also it was trying to generate one.
From the beginning of my project, I use a custom framework, let's call it "custom.framework". But there was a bug in this framework and now I want to use another version of the "custom.framework".
At first, I simply removed the "custom.framework" file from my project and added the new one. But nothing changed, the bug was still there.
After multiple tries and hours, I understood that Xcode add the old version in memory and used this one instead of the new version. I know it because in the new version I added a method and when I cmd+click the class I've add the method into, it's not there and the file's path is unavailable.
Searching through the web, I tried to change some version parameters to my framework projects: Compatibility version, Curent Library version, Framework version. But this didn't change anything to Xcode which keeps using the old version.
I also tried to make the framework's project as a sub-project and add resulting framework as a dependency to my target. It worked well, but as the framework's project is on a separated remote git repository, I don't think this is an acceptable solution.
So my last try was to build a "custom2.framework", to force Xcode to use the real file and not some cached version. But again, it doesn't work and when building I get errors telling me that all my classes in custom2.framework are duplicated symbols of its cached version of "custom.framework".
So my question is simple: how can I finally tell Xcode to deleted its cached old version and let me use the file I gave him? I already tried to delete my project's derivedData but it seems cached frameworks aren't there.... I'm so desperate :(
Edit: Here are 2 screenshots to illustrate the issue
First screenshot is the path as shown by Xcode when I opened the file from the .framework object in the project navigator.
Second screenshot is the path as shown by Xcode when I opened the file from a cmd+click to a "DCEquipmentManager" in code.
As you can see, the framework linked with the code is not the framework in the project.
it seems problem with binding in new framework, your project still linked with old framework files.
try to remove all files and folder related to your "custom.framework and also remove path for that framework from project setting--> build setting --> search Path
Then after Drag and Drop Your "custom.framework" files in project.
it works for me.hope it resolve your problem.
Please try to clear derrived data:
Window -> Organizer
at the right side you will see projects list. Find your project and tap on it. I the top part of window you will see button delete in front of Derrived data, tap on it.
I guess it will solve your problem.
It might sound silly, but sometimes restarting XCode or the whole machine fix things.
Did you remove the old framework from Build Phases --> Link Binary With Libraries?
Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.
First lets say something upfront. The build stage is a(are) command line tool(s) that is managed by Xcode according to your Build Settings.
So when Xcode doesn't find your Framework - the Build System will usually also not find it. This forces you to act but may end up in confused Xcode to catch an older reference.
Yes it may happen that the Header Xcode is pointing to is correct but the build system still uses an old copy somewhere. An outdated copy can dangle around literally anywhere depending on the steps you took before.
It (Xcode) assumes where it is located but the Build System still uses another version or the Search Paths just pointing in the wrong Locations even if they are visible to you and even your Framework icons are visible in the lists. So when you erase the last build you actually only force Xcode to rebuild from the known arguments, the settings stay the same, the lists stay the same. Even restarting Xcode does not change anything, the problem persists.
Ergo: Compiler Instructions, Xcode settings and Build System settings don't match what the code tells with #import <NAME/Name.h>
So you will check at least those 6 stages again:
Is your Framework Header File published in your Framework project?
are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?
Is your Framework in linking list?
Is your Framework in Embed Framework list?
Does your framework appear in the Framework Group Folder in Workspace/Project Browser? (usually the very last Group Folder in the Browser below all your other files)
Is my Folder Structure correct?
At least 1 to 4 must be right otherwise it will fail.
Here a random list of common causes
Framework is located outside your Source Paths structure
Structure got changed after you added it to the project
You use Workspace's where Framework development and Final Application can appear side by side but you assume Xcode uses this to change its Search Paths
The contained build settings are misleading from former drag and drop operations, ending up tricking Xcode in the "wrong" corner. In this case recreating a project is just one of the possible ways to fix it but not the solution.
Also dragging a Framework into your Project > General or separated in Build Phases > Link Binary list or Embed Framework lists does not make Xcode aware of the wrong Build Settings.
The Linking works, embedding works, but compiling does not. The Header information is still missing.
The solution must be to correct your Build Settings.
As mentioned above Build System and Xcode are two different things. In particular only setting the right Framework Search Paths will solve those issues, even if you managed to kick your derived data manually.
Erasing Derived data?
Derived data is the place where precompiler collects data to compile. So it can be seen as expression of what all the settings are told to do. Erasing it does of course not change the settings but may fix inconsistencies related to former Build Settings. It would erase the derived data and rebuild from the Build System Settings you gave.
Correcting Linking?
Also Linking is not the same as making Xcode aware of the desired Headers. Linking is for your final Product to know where Symbols are to call on them at runtime, it does not change Framework Search Paths and System Framework Search Paths, they stay the same as given.
But it is not wrong to start fixing first with
Product > Clean Build Folder, it forces your build to parse all and compile all again on the next Build.
When the troubles come up because of folder structure in parallel or Frameworks are simply placed outside the Source Directory then you must point to them directly or relative.
Most likely you should place one extra entry in your Framework Search Paths like $(SRCROOT)/../Yourframeworksource/build/Debug. expression to point to relative higher folder structure.
Needless to say that a Release Build likely needs another entry ending in "/Release".Hint: Well you can have different Search Paths for different Compile Schemes..
This works particular good after you cleaned Linking List, Embed Frameworks List and then also check the very last Group Folder "Frameworks" for double entries to drag and drop a fresh Framework reference in there.
How to know if leading /../ will fix it?
Click on the dropped Framework Icon inside the workspace Framework Group Folder (lower most) while your Project is the active selected to work on, now watch for the relative Path information on the very upper right side of Xcode, if there is some /../ you know you need it as well.
Sorting of Framework Search Paths
play a role of course, just the same as #import/#include rule sorting matters.
Remember the first found, first wins rule because often we use #import that works different then #include but ignores second attempts to declare. This leads to once wrongfully declared headers to hide corrected declarations later on in parsing that share the same filename or define rules
#ifndef xyz
#define xyz
// all your code here.
// a second read attempt would be ignored
// a second read is hidden also when you use #include then.
#endif
So you can sort those entries either by code and/or in the build settings if needed because of course it matters what is declared before other declarations depend on it.
When I'm writing simple code in ViewController, I wanted to run it and boom. Apple Mach-O linker error as shown. I don't know what is the problem. Then, I've made a quick research, according to research; I deleted Derived Data folder, I deleted Derived Data folder contents, I deleted test hosts in build settings(it is already empty), I cleaned the build folder and I applied clean action. But nothing changed same errors. Is there any specific solution of this error depends on app and what is that solution?
EDIT:
I moved the codes to a new xode project and I noticed that when I add the line let ftp = CkoFtp2(), the error occurs otherwise it compiles. But it is coloring the CkoFtp() part of line and I'm not getting any specific errors there. Just Match-O and linker command.You can see the CkoFtp2 code here.
I had the same issue. Please make sure to follow the directions on chilkat's site, particularly the following:
Add libChilkatCocoa.a to your list of libs for linking. In your project build settings, find Build Phases, Link Binary with Libraries, select Add Other, navigate to the libChilkatCocoa.a, and add it.
The Chilkat library internals are written in C++. Therefore, your Swift application will need to link against the C++ runtime libraries. In your Build Settings, go to the Linking section and add -lstdc++ to the Other Linker Flags.
https://www.chilkatsoft.com/chilkatSwiftCocoa.asp
I also ran into trouble because the libChilkatCocoa.a library resided in a folder that had a space in its name. Avoid that, or make sure it is correctly escaped under Build Settings.
Looks like you've got a reference to a framework located in your Downloads folder. Chances are you moved that somewhere else, yes? Remove the SimpleUnzipper framework from the project and re-add it from wherever you moved it to.
After the edits, this is clearly not the problem...
It's hard to tell from just the error message, but it appears that you're using a library that you downloaded from another developer. Are you sure you followed their instructions for setting things up? The linker error means that you're not linking your program with the library, though it looks like you've managed to set up a bridging header so that you can call the function without getting a compiler error.
I have a very annoying problem.
I backed up my code on Dropbox but now i get this error while compiling
clang: error: no such file or directory: '../firstFoo-Prefix.pch'
Since the only .pch file in my project in Xcode and my project folder is secondFoo-Prefix.pch and I don't know how to fix this error I've decided to remove every .pch file so i went into Project> Build Settings and removed everything in the Prefix Header and set Precompile Prefix Header to NO.
Before this the Prefix Header had value secondFoo-Prefix.pch and not firstFoo-Prefix.pch.
Even though the compiler should not look for .pch files I still get that error.
I've looked everywhere in my project but I can't seem to find anywhere firstFoo-Prefix.pch.
Any ideas?
Thank you
This can occur (not your fault) when the Xcode project file database gets messed up such that the referenced file does not appear in the navigation area but is still somehow included in one of the various list of files used for the build phases.
To see if this is the case:
In the Finder, right click on the project file and select 'Show Package Contents'
Right click on the file 'project.pbxproj' and 'Open With->TextEdit.app'
In TextEdit menu: 'Edit->Find->Find...' [or command-F] then enter '.pch'
Look at all occurrences of '.pch' [command -G to move to next one]
If you find occurrences of '../firstFoo-Prefix.pch' then your project file is corrupted. Looking at the context of the occurrence(s) will give you some indication of which area the corruption occurs in (e.g. build phase compile files list).
Sometimes just deleting those references (after having backed-up the project file of course) has worked for us but other times it just makes matters worse. The safest recovery is to create a new project file and copy over all the folder groups and settings manually. Your source code is all fine, it's just the cross-references and build settings that need reworking.
Do a clean for build using this combination: Shift+Option+Command+K
In my case, I have Framework which need to add to main project from derived data after it building successful. So copy items if needed was not tick marked and that's why giving error and also #ZAZ and #chiwangc mentioned cleaned it before building.
I Have an iOS application that I am trying to add OCMock to in order to better unit test it. I've followed the instruction on ocmock.org as well as instructions I've found in other places but still I cannot get my test code to compile.
Here's what I've done
Added the source code to my project directory
Create the groups in my project to mimic my file system
I selected the option to add to my test targets so the framework was added appropriately as well as the Library Search Path
Then I manually added the headers to the Header Search Path
And added the -ObjC linker flag
Then when I go to import the header file, I get the file not found error
Any ideas what I am missing here???
You have the search path test/libraries/OCMock. Then you have #import <OCMock/OCMock.h>.
This fails because there is no file test/libraries/OCMock/OCMock/OCMock.h.
You use the search path test/libraries, or you can create a prefix directory to hold OCMock and have the search path point at that.
I generally have a directory with the library name and version number before the actually directory.
The directory test/libraries/OCMock-X.X.X could contain the OCMock directory. That way the search path still be more specific: test/libraries/OCMock-X.X.X and you still use OCMock/OCMock.h as the include.
One more thing to check, for anyone else having this problem - I copied OCMock from one project to another and everything looked right, but it wasn't finding the include file. It turned out that even though I had the right groups in Xcode, the files had all been dumped into one directory. I needed to create folders on disk and associate them with the groups in Xcode. The accepted answer here clued me in to what was wrong (though as is often the case, in hindsight it should have been obvious).