xcodebuild 7.3 can't enable bitcode - frameworks

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.

Related

Xcode 10 archive build compile failure

Building on devices and simulator works fine in Xcode 10 but an archive build in Xcode 10 hangs up at the same spot each time (cpu maxes out too), at the very end of "Compile Sources" but never goes to the next build phase. Of course, when I quit the build I get an uncategorized SwiftCodeGeneration warning (also using legacy build system also fails, also same happens before and after updating to swift 4.2). Anyone else running into this?
Another note, not using cocoapods, tried removing all my embedded frameworks and still had the same issue.
remove the armv7 from supported architecture works for me
I found some answers to this problem.
I adjusted the level of optimization, this allowed me to get past the "compile sources" build phase (in particular "fastest and smallest" and "optimize for speed").
the compiling then got stuck on the "copy bundle resources" phase. making sure my project folder names matched the actual folder names and making sure all my resources were linked properly by deleting the reference to a few and re-entering them into the project I was able to successfully compile. Again this was a project that worked a couple days ago on Xcode 9. Hope this helps someone, cheers.

XCode 8.0, Building for Store Submission, Errors

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.

Getting dyld_fatal_error after updating to Xcode 6 beta 4 using swift

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

Make command line compiler work with Xcode 4.3

I have Xcode 4.3 and it works fine. However, running make to compile a program from the command line gives me many errors about missing standard headers, such as
error: stdio.h: No such file or directory
The problem may be that Xcode 4.3 (as opposed to older versions) is installed like a standard Mac app bundle (no installer inside a dmg..) so the paths don't get set up automatically.
How can I setup the command line tools to look into the /Applications/Xcode.app/ bundle and its subfolders for the standard headers and libraries?
$ which make
/Applications/Xcode.app/Contents/Developer/usr/bin/make
With the full release of XCode 4.3 (and OS X 10.7.3) you can go to Preferences > Downloads > Command Line Tools and click 'Install'.
It appears that you need to have a developer account though.

Code Coverage GCov not working with XCode 4.2 and iOS SDK 5

I've been trying to get GCov working with Xcode 4.2Build 4D199 on Lion with iOS SDK 5.0 to no avail. Has anyone had any luck with this? I'm using Google Tools For Mac for my unit tests and I've linked in libprofile_rt.dylib and added:
"OTHER_CFLAGS[arch=*]" = (
"-ftest-coverage",
"-fprofile-arcs",
"-falign-loops=16",
);
as indicated on the Coverstory page here http://code.google.com/p/coverstory/wiki/UsingCoverstory
But when I find . -name *.gcda" I come up empty. What am I missing?
GCov is no longer supported in XCode 4.2. You'll note that if you go their "man page" for it, XCode 4.2 is not an option in the drop down list. Furthermore, if you look at the compile, it's using "c++", which is linked to llvm-g++-4.2. They now exclusively use the Clang/LLVM tool chain (which in turn often makes use of the gcc tool chain) instead of giving you the option of directly using the gcc tool chain. A consequence of this is that doing code coverage in XCode4 with gcov is no longer directly available. This also can affect compiles using CMake that bypass XCode 4. That first link gives you instructions on how to change your project to use profile_rt instead of gcov.
How to generate coverage test reports (Xcode 4.5 edition)
cd to your Xcode project and type
git clone git#github.com:j4n0/XcodeCoverage.git
cd XcodeCoverage
wget http://downloads.sourceforge.net/ltp/lcov-1.10.tar.gz
tar -zxvf lcov-1.10.tar.gz
Set the following build properties on both your main target and your SentestKit target, but only for the Debug configuration (expand the node, there are Debug and Release entries):
Generate Profiling code Yes
Generate Test Coverage Files Yes
Instrument Program Flow Yes
Install Xcode command line tools: Xcode > Preferences > Downloads > Command Line Tools.
In your main target, add a “Run Script” build phase to execute ./XcodeCoverage/exportenv.sh
Build your application, and run the tests.
Generate the coverage report from the XcodeCoverage typing: ./getcov
Upon completion, the script will launch a browser with the html output.
If reports are not generated try this:
Edit the plist of your application and add the following:
<key>UIApplicationExitsOnSuspend</key>
<true/>
Then run your application and press Home. This will quit cleanly and generate the gcda files.
If it still doesn't work, try using the iPad simulator instead.
For more tips and tricks check the talk Code Coverage on iOS by Richard Buckle.