SQLCipher runs successfully with simulator but doesnt build with device; instead I get the following errors:
cp: libssl.a: No such file or directory
and
sqlite3.c:91838: internal compiler error: in find_src_set_src, at var-tracking.c:1922
I have followed the entire procedure given at SQLCIPHER website. And it runs successfully on simulator but when i change it to iOSDevice the above errors appears.
Kindly help me asap
Please make sure you are using the official 2.0 release from this repository, https://github.com/sqlcipher/sqlcipher, It addresses an issue building for armv6.
Open openssl.xcodeproj and follow instructions form this site:
http://programmer-in-paradise.blogspot.com/2011/07/how-to-build-openssl-in-xcode.html
You need to setup a new target then bring libssl.a in your project.
If you still have problems:
As XCode 4.3(2) complains in release and test on device (not in simulator) about arm 6, better is to compile your own openssl libraries [see http://www.x2on.de/2010/07/13/tutorial-iphone-app-with-compiled-openssl-1-0-0a-library/]. You just need to adjust some paths [like /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk and /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs, if you're familiar with scripting]. I managed to build libs for last version of OpenSSL [2012 openssl-1.0.1c], then include in my project and able to build release and archive for distribution, with encrypted db.
Related
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.
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.
when i am trying to run my app on device i got the following error.
CodeSign error: code signing is required for product type 'Application' in SDK 'iOS 6.0'.
After changing any ios sdk in build settings to iPhone Developer now am getting the following error.
/Users/chandrasekhar/Library/Developer/Xcode/DerivedData/UnitConverter-
dhznawqrnkbqwvcrkgpzpkjmooox/Build/Intermediates/UnitConverter.build/Debug-
iphoneos/UnitConverter.build/Script-50524F424C454D533F.sh: line 4:
/Library/JailCoder/Entitlements/Entitlements.py: No such file or directory
help me solve this error. Reinstalling Xcode is not working
Download Jailcoder again and Unpatch the project.
It looks like the script is using JailCoder, which doesn't appear to be installed (or requires re-installing).
got It! I couldn't get jailcoder to unpatch so what you must do is go into the build phases and remove the part that inserts jailcoder into the build phase pretty easy once you take the time to dig into the guts of the app!
I retrieved the latest build from the SVN trunk on Friday and attempted to build following the directions on the getting started wiki.
make dep seems to execute without any problems, but make fails on Samples.mak. It appears there are no rules to make any of the samples when the platform is "arm-apple-darwin9".
If I open the Xcode project at this point, libavcodec and all it's related libraries are missing as well as LibSDL. There's not mention of a requirement to install SDL and ffmpeg beforehand, so not sure what to do there.
Please add some framework is required for run pjsip and also checked config_site.h this file available or not if not found then add this file. some code also may to write in config_site.h file .
I'm trying to produce gcd a files from an iOS Xcode 4.2 (4D199) project called CocoaTouchHax on Lion and I'm having incredible trouble. I followed the steps here and I went as far as trying to build llvm/clang from source following steps here. However I continue to get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
Where am I going wrong? I've tried to use the install_name_tool to fix the executable path to no avail. Am I over analyzing something? Am I missing something simple? I put this in as a "Run Script" phase prior to linking to ensure I've updated the #executable path and I use tool to examine the file after and the name is updated:
install_name_tool -id #executable_path/Users/cliff/dev/CocoaTouchHax/build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib
What am I doing wrong? Help!
Update
Merely adding lib profile_rt.dylib crashes my test run immediately giving the following error when anything is run:
#executable_path/../lib/libprofile_rt.dylib
So I am certain that something needs to happen or something needs to be done to the lib profile_rt.dylib prior to execution.
Another Update I tried creating a sum link to
/Developer/usr/lib
under /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr
Which I believe is part of the base the path forming the current working directory when test runs. (Assuming it runs from the bin folder there.) This would, in theory, complete the relative lookup path of ../lib/libprofile_rt.dylib from that base path but it didn't work. I've tried running the install_name_tool command prior to copying the dylib in place but I still get this error:
Library not loaded: #executable_path/../lib/libprofile_rt.dylib
I don't know what I'm doing wrong. I somehow did manage to get test coverage files to emit using some combination of the above but I was not paying close enough attention and cannot reproduce the occurance. I know this can work, I just need a little more help figuring out how.
Update: In Xcode 4.3.2 (4E2002), just switch on Generate Test Coverage Files and Instrument Program Flow, the build system will link libprofile_rt for you. Xcode 4.3, and later, is a standard Mac app and the /Developer folder is gone. So, skip steps 5-7 below. You will also have to create a class file to workaround a bug in Apple's unix implementation as described here. You'll want it in the project under test.
For Xcode 4.2 (4C199) in Snow Leopard:
Create a project, say MyProduct. Check Include Unit Tests.
Once Xcode does its thing and loads the new project, you should have two targets, MyProduct and MyProductTests. Duplicate the MyProduct target.
Select the MyProduct copy target.
Go to Build Settings. Under Code Generation turn on Generate Test Coverage Files and Instrument Program Flow.
Go to Build Phases. Expand Link Binary With Libraries. Click the +. Click Add Other.... Browse to /Developer/usr/lib. Choose libprofile_rt.dylib.
Select the MyProductTests target.
Repeat steps 4 and 5 for that target.
Go to Build Settings again. Find Bundle Loader under Linking. Change the path to the MyProduct copy app. Something like $(BUILT_PRODUCTS_DIR)/MyProduct copy.app/MyProduct copy.
Change your schemes so that the tests run under the MyProduct copy scheme and not MyProduct. If you're compiling clang on your own, you can figure out the details here.
That should work. Step 8 took me hours to figure out, it's the key. If you only see gcda files in the test build directory, that's the likely issue.
On Lion you can symlink the dylib into /usr/lib to avoid that error
sudo ln -s /Developer/usr/lib/libprofile_rt.dylib /usr/lib/libprofile_rt.dylib
I cant guarantee that that wont bust something the future however. Remember that you have done it.
Create a new configuration called "Coverage" (or whatever).
In the Coverage config variant you have created go to Build Settings and...
Add -fprofile-arcs and -ftest-coverage to Other C Flags
Switch on Generate Test Coverage Files
Switch on Instrument Program Flow
In Other Linker flags add -lprofile_rt
The reason to do it this way with a config is that you can keep your normal build untouched. Also only works on Simulator. So dont try running this on device.
And from http://mattrajca.com/post/8749868513/llvm-code-coverage-and-xcode-4
Finally, open up the Intermediates/$TARGET.build/$CONFIG/$TARGET.build/Objects-normal/$ARCH subfolder. Inside, you’ll find the aforementioned gcda and gcov files
You can open that folder with CoverStory.
Note that coverage is not cumulative (unlike Coverity) so each run starts afresh. There might be a way to change that.