Getting the following errors with XCODE 8.0. This was working fine with Xcode 7.x as far as we can remember.
ERROR ITMS-90087: "Unsupported Architectures. The executable for xxx.framework contains unsupported architectures '[x86_64, i386]'."
Does this mean that Apple is not smart enough not to include the simulator slice? We have to provide an SDK that has the simulator and does not?
ERROR ITMS-90209: "Invalid Segment Alignment. The app binary at 'XXX' does not have proper segment alignment. Try rebuilding the app with the latest Xcode version."
But we are using the latest XCODE 8.0 version? What gives here?
ERROR ITMS-90125: "The binary is invalid. The encryption info in the LC_ENCRYPTION_INFO load command is either missing or invalid, or the binary is already encrypted. This binary does not seem to have been built with Apple's linker."
Not sure what this is. All Signing stuff is set correctly in all of the builds. Again, this was working fine before. We did use LIPO to make the universals. So maybe stripping the universals would do it????
WARNING ITMS-90080: "The executable 'Payload/mediumSDKSwift.app/Frameworks/VRSDK.framework' is not a Position Independent Executable. Please ensure that your build settings are configured to create PIE executables. For more information refer to Technical Q&A QA1788 - Building a Position Independent Executable in the iOS Developer Library."
All PIE stuff was working find, no changes, etc. All are set to NO for Position Dependent. Have been doing some reading on this and some have solved by flipping bits? hmmmm.....
ERROR ITMS-90087: "Unsupported Architectures. The executable for xxx.framework contains unsupported architectures '[x86_64, i386]'."
This is a known Apple bug.
Your other errors are resulting of manipulating an already signed product, so you have to code sign your product again after you sliced out the unsupported architectures.
Workaround:
The Carthage installer comes with a handy script, which I am using as an easy workaround.
1) Install Carthage
2) Add Build Phase Script
From Carthage site:
On your application targets’ “Build Phases” settings tab, click the “+” icon and choose “New Run Script Phase”. Create a Run Script in which you specify your shell (ex: bin/sh), add the following contents to the script area below the shell:
/usr/local/bin/carthage copy-frameworks
and add the paths to the frameworks you want to use under “Input Files”, e.g.:
$(SRCROOT)/Carthage/Build/iOS/Box.framework
$(SRCROOT)/Carthage/Build/iOS/Result.framework
...
Turns out we were providing a Universal Framework by mistake. Once this was solved all of the errors were solved.
Related
I'm developing an embbeded framework for iOS. In order to make an universal fat (with simulator and device slices), I created an aggregate target with a script that uses xcodebuild and lipo commands to generate it, as many people does.
With XCode 7.x I had to add an user-defined settings with BITCODE_GENERATION_MODE=bitcode in order to enable it, but this has stop working since the last XCode 7.3 release.
I've tried everything I found in the internet like add OTHER_CFLAGS="-fembed-bitcode", but anything works as before...
I have seen this in the build log:
ENABLE_BITCODE is always NO, no matter I do.
Has anybody tried to create an universal fat framework with bitcode enabled using xcodebuild command since XCode 7.3?
I ran into a similar issue yesterday. After some investigation, the problem, that appears when running xcodebuild from a "Run Script" build phase in any Xcode target, seems related with the explicit specification of the toolchain to be used, done with the ENV variable TOOLCHAINS.
Therefore, until Apple releases a fixed version of Xcode 7.3, you can try to add the following command at the beginning of your script:
# workaround for bitcode generation problem with Xcode 7.3
unset TOOLCHAINS
This should be harmless, as this env variable is not set by default when you run xcodebuild from the command line, and this workaround works just fine in my case.
I'm facing the same issue. Just like you, BITCODE_GENERATION_MODE and OTHER_CFLAGS="-fembed-bitcode" are simply ignored, and my builds broke
I did notice that it sometimes work, and sometimes doesn't. It seems that if you build the framework (or aggreate target) for the simulator, the bitcode goes away, no matter what you have in the xcodebuild commands.
I'm using Xcode 7.3, and I have 2 targets : Static Library, and Aggregate target to make the fat framework.
What works for me when it builds a bitcode-less framework, is to:
Select the static library target (not the aggregate one), and pick "Generic iOS device"
Clean it
Select the static library target, but pick a simulator
Build it (works, even if it's instantaneous because it hasn't been cleaned)
Select the static library target, but pick "Generic iOS device" again.
Build it
Select the aggregate target for a "Generic iOS device"
Finally, build it
If this failed, start over. I sometimes need to do it two or three times before it works.
When I do that, my fat library ends up having bitcode.
You can check that your framework has bitcode support easily by running otool -arch armv7 -l <framework_path> | grep LLVM
In order to break it again, simply build the aggregate target for a simulator. The library will still be a fat one, but bitcode's gone.
Somebody surely can find a solution that works everytime, but at least it fixes the issue for me.
I certainly did not have to do that with Xcode 7.2, and I don't know how that works for pure CLI builds.
I just recently downloaded Xcode 6 beta 4, and my swift project compiles with no errors but before it gets to my code I get a dyld_fatal_error just above start in the call stack.
and a breakpoint in some assembly code with a nop instruction
The console error I get is
dyld: lazy symbol binding failed: Symbol not found: __TFSsa6C_ARGVGVSs13UnsafePointerGS_VSs4Int8__
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/Sudoku
Expected in: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/../Frameworks/libswift_stdlib_core.dylib
dyld: Symbol not found: __TFSsa6C_ARGVGVSs13UnsafePointerGS_VSs4Int8__
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/Sudoku
Expected in: /Users/username/Library/Developer/Xcode/DerivedData/Sudoku-dhrdonaeqzsgcvewndimxbbsltnc/Build/Products/Debug/Sudoku.app/Contents/MacOS/../Frameworks/libswift_stdlib_core.dylib
Just so you know the project still compiles, and runs fine with Xcode 6 beta 3.
Most extremely weird problems like this can be solved with a Clean & Build (or perhaps relaunch Xcode). You might also consider deleting the relevant folders from ~/Library/Developer/Xcode/DerivedData.
For sure this error is very unhelpful:
dyld`dyld_fatal_error:
-> 0x1200ad088 <+0>: brk #0x3
This of course occurs only on device, not the simulator. Another good reason to always test on a device.
Anyway, having had the same issue, a clean didn't work for me. Deleting DerivedData didn't help either. Also tried synchronising the Deployment Target versions. That didn't seem make any difference but I did it anyway.
Solution was to add any dynamic frameworks to Embedded Binaries setting under Target -> General:
Now I know that has been mentioned in other answers. However, if I can supplement by saying that any dependent dynamic frameworks must also be included.
So for example if you have a dynamic framework A that depends upon dynamic framework B, then it's necessary to have A and B added to Embedded Binaries.
Note that if the dynamic framework A depends upon any static library or framework, you will almost certainly be forced to create A as an umbrella framework that includes the dependant binaries.
Other considerations that may or may not be important. However did personally for me result in success were;
paths of each dynamic library in the Inspector were set to "Relative
to Group". In the screen grab above the path of the embedded binary
appears correct terminating with "build/Debug-iphoneos".
dynamic frameworks are in embedded binaries section. Static libs and
static libs wrapped up as frameworks are in Linked Frameworks
and Libraries. Nothing appears in both sections.
In setting this up XCode behaved strangely. The following proved successful:
Add the dynamic framework to the embedded binaries.
Find the new framework in XCode groups on the left and update the path to be
"Relative to Group" as described previously.
Delete the dynamic framework from embedded binaries.
Add the dynamic framework to the embedded binaries again. The path should now appear correctly.
Delete all references to the dynamic framework from the Linked Frameworks
and Libraries section.
I have just had this problem trying to link a custom iOS framework to my project, so for anyone out there who has this problem, it's to do with the copy files build phase.
I think that this error results when a file cannot be found. So create a copy files build phase in the appropriate target in your project. Then add the file (in my case the custom framework) to this phase (if it's a framework make sure to select the 'Frameworks' destination).
Cleaning, restarting, deleting etc didn't work for me.
I have a project containing another project. When I ran the project on iOS 7 and the contained project was accessed in code, the app stopped at the line below:
After many days, I saw that the deployment target for the container project was 7.0 (as can be seen below).
The contained project on the other hand, had a deployment target of 8.1 (as can be seen below).
Changing the deployment target of the contained project to 7.0 solved my problem!
The project was working fine on iOS 8 devices.
I had this issue recently and the problem for me was that I had added a library from the same project which wasn't listed in 'Embedded Binaries' from the 'General' section.
NOTE: If you add it in Embedded Binaries it will also add to the Linked Libraries section, possibly adding the same one twice.
Clean and build won't work. You'll need to delete he cache in ~/Library/Caches/com.apple.dt.Xcode* directories. Delete these and rebuild.
Do this every time you upgrade the beta.
I also faced the same issue and tried all the solution given above without any luck.
then what I have done to resolve that I really don’t have much I idea about. So there is Certificated called “apple worldwide developer relations certificate authority” in System group in keychain Access and due to some profile and certificate issue I randomly mark this certificate “Always trusted” from “Use System Defaults”. So this is causing this “dyld_fatal_error” crash to me. when I revert it back to “Use System Defaults” crash got resolved.
So guys if you are tried all the possible option to resolve this crash and didn’t succeed yet, try this also. It helped me, may help you as well.
Found this about this certificate.
This problem still occurs in Xcode 7, and it can happen for a variety of reasons (it seems). In my case, the iOS app with an included framework:
ran on the simulator fine
gave the error you described on the device
The answer was to NOT use linked libraries but rather Embedded Binaries under General.
Also see here: https://stackoverflow.com/a/34052368/8047
Adding the non-system Framework to "Embedded Binaries" inside the general tab of the main project worked for me.
As stated by bitwit, this will also add your framework to "Linked Frameworks and Libraries", so watch out for those duplicates.
Tested with Xcode 7.3.
Xcode 8.
Clean and build didn't work. I deleted the cache, deleted Derived data. After that, my pods configuration was broken, so i needed to install pods again. Pods Target configuration was set to a very old Valid architectures. setting to armv7 and armv7s, was ok to compile and no problems
You'll get this if your scheme has "Guard Edges" enabled in diagnostics when running on an actual device. "Guard Edges" only works in the simulator.
I was using cocoapods and had this problem as well when I updated to deploy target iOS 8 and added use_frameworks! to my Podfile. I was able to fix it by adding the following line to my Podfile:
link_with 'TargetName1', 'TargetName2', etc.
Might work with ProjectName as well
I've recently stumbled upon a rather odd problem with Xcode which occurs when I build an IPA and attempt to install it, I've tried installing using Xcode, iTunes and iPhone Config Utility, all of which give the same error
A signed resource has been added, modified, or deleted.
I can successfully debug the app on my phone using XCode, it's only when I try to install an IPA I see the error.
I've tried unzipping the IPA and running the codesign validation tool which throws up the following response:
a sealed resource is missing or invalid In architecture: armv7
resource missing:
/Users/dev1/Documents/PoleTester.app/Settings.bundle/._Root.plist
This led me to look at the Settings.bundle file and ensure that it's being included in the build, which it is. Interestingly though, if I remove the Settings.bundle file, build an IPA and attempt to install it on my iPhone the install succeeds, however this of no use as I need the Settings.bundle file installing with the app.
Further investigations on some of my previous XCode projects has shown that I can build an IPA, with the Settings.bundle file included, and successfully install it. However, if I make a simple change to the Settings.bundle file, such as adding or removing a row, build an IPA and then attempt to install it I get the
"A signed resource has been added, modified, or deleted" error.
I'm at a bit of a loss as to what's causing this error and why the Settings.bundle file is causing the install to fail.
Has anyone seen this error before or potentially shed some light on what's causing it?
I'm using Xcode 4.6.3 and an iPhone 4 running iOS 6.1.3.
Clean Build Folder (⌘⌥⇧-K) has resolved this for me 3 out of 3 times.
I just ran into this issue using Xcode 6 beta 6 installing to my iPhone 5 running iOS 8 beta 5. The app I'm building uses a Today extension (aka widget).
It appears the issue stemmed from my having not set up dependencies properly. I have a third party framework (Alamofire) set up as part of the project as a dependency of the overall project, but not as a dependency of the today widget. I could build fine but when installing to device I would get this "signed resource has been..." error.
By adding Alamofire as a dependency of the Today widget this resolved the issue.
It's a bit late but I ran into the exact same issue today with Xcode 5.0.1.
According to https://developer.apple.com/library/ios/technotes/tn2318/index.html, "the resource missing: my.app/..*" error could be caused by:
The file prefixed with "._" is considered an AppleDouble file and it can result from copying the uncompressed Xcode project folder onto a non-HFS+ formatted disk. The AppleDouble files must be removed using the 'dot_clean' command. The Xcode project folder is the argument to dot_clean as illustrated below.
Steps I did to resolve this:
Close Xcode
Run "dot_clean /path/to/My_Xcode_Project" in Terminal
Open Xcode again and make a new build
Oddly enough most of these _* files don't seem to cause any issues except those inside Settings.bundle (Nearly every file in my directory had one, but only after I added Settings.bundle, the IPA failed to install).
I also faced the same issue and this post solved my problem:
http://code-ninja.org/blog/2012/04/17/signed-resource-has-been-added-modified-or-deleted/
It turns out that the problem was caused by having special character in the product name – in my case, a ?. Removing the ? from the product name fixed the problem.
In my case, what helped was adding a bash script into build phases (just before "compile sources"):
find ~/Library/Developer/Xcode/DerivedData -name "YouAppName.appex" | xargs -I % find % -type f -maxdepth 1 | xargs rm
What this script does, is to clean files in project's appex dir (e.g. assets), but leaving sub-directories (e.g. compiled storyboard). In effect, using this script while building is much faster to execute than full project clean.
I'm trying to validate my App for App Store Submission, I've made an update to it. It was using Three20 before, though I'm not sure what version, probably 1.0.3. Now it's using 1.0.5 and I have rerun the python script that adds Three20 to an app with the --xcode-version=4 flag.
I have no linker errors, and it archives fine, but I get the following errors when I try to validate the archive for distribution:
I'm kind of at my wit's end, been dealing with linker errors all day, and general problems with Three20 and Xcode itself. Is there anything obvious I might be doing wrong here?
The binary being analyzed must be an executable:
Check your build settings, because something's fishy. Your Mach-O type should be set to executable:
Application failed codesign verification...
You must sign your executable with a Distribution certificate, you're most likely signed with a Development certificate, or not at all.
The binary being analyzed must exist:
This is probably coming up because of issue number one. Resolve the Mach-O type, and this should vanish instantly.
Since upgrading to Xcode 3.2.1, I've experienced a strange issue that has really killed my workflow. The issue only exhibits itself under my own user account (the same project opened by a different user works fine). Therefore, the heart of this question is, "what does Xcode load from the user directory that could conceivably cause this issue?"
(System: Snow Leopard 10.6.1; Xcode 3.2.1 w/ iPhone SDK 3.1.2)
Symptoms:
Code completion only works on symbols of the current class or already referenced in the class. Virtually useless.
Document/reference lookups (i.e. option-double-clicking on an identifier or symbol returns this strange result): "Documentation not found for the symbol 'symbol name'. Click here to view symbol declaration."
Like I said, since other users are experiencing normal behavior in Xcode, this must be due to something only loaded for my user account. I've already eliminated ~/Library/Preferences/com.apple.Xcode.plist, ~/Application Support/Developer,~/Application Support/Xcode`.
The only thing I've recently installed is mogenerator (the defunct xmod integration may have killed it, but it doesn't install anything to the user directory)
Update: 10/26/09
This one is really starting to kill me. I did a fresh OS X install, followed by an Xcode 3.2 install from the Leopard disc, followed by an iPhone SDK install from the ADC site, and this started occurring again within 30 minutes of my having started working. I'm at an utter loss. The error is most obvious when option-double-clicking on a symbol (say, the NSString class) and instead of getting the documentation snippet, a message "Cannot determine the symbol for the current selection." appears.
Update: 10/26/09 #2
I just tried creating a fresh project, and that project's symbols are appearing fine. So the issue is apparently local to my project. Hopefully that's a better start. To demonstrate what I'm talking about, here's a screen of the issue manifesting itself with respect to documentation:
Have you tried rebuilding your CodeSense index? Project > Edit Project Settings > General >
alt text http://idisk.mac.com/cdespinosa/Public/Rebuild.png
After doing that, check Console.app to see if Xcode issued any warnings. It's possible that some of your source code causes the indexer to stop, and you don't end up with a valid index. Filing a bug with Apple and providing the source, if possible, would help Apple fix problems like this.
This is the first thing I'd try:
alt text http://img.skitch.com/20091026-ek3id5s121wqrsiu8apwm4qgir.png
Wait until it doesn't say "Getting" anywhere anymore before doing anything documentation related.
Given the clues from the console:
10/26/09 7:21:58 PM Xcode[19072] Warning: Couldn't discover the 'clang' compiler's built-in search paths and preprocessor definitions for language dialect 'objective-c'. This may lead to indexing issues.
Compiler: /Developer/usr/bin/clang
Reason: clang version 1.0.1 (http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-24 exported)
Target: x86_64-apple-darwin10
clang: warning: not using the clang compiler for the 'armv6' architecture
I'm going to say that you tried to configure an iPhone Device build to use the Clang compiler, which is not yet supported for compilation. (It works for static analysis, but not for building).
Find the Compiler Version build setting and set it back to gcc 4.2.
I had this same problem and I was able to workaround it by:
Setting the target to be the iPhone simulator
Quit and relaunch Xcode
Rebuild the index
Clean and rebuild the simulator target
Maybe it's a bug in Xcode with iPhone device selected when a project is first opened.