libCrypto on iOS and simulator


#1

I have sqlcipher building ok for ios builds, but when I try to build for simulator link fails with OpenSSL libcrypto. It lacks the architecture required for simulator (i386 I think). Any ideas on how to fix this? It seems when I add i386 to the OpenSSL Xcode target the library doesn’t build properly.


#2

@XPlatform Hm, the ARCHS setting might need to be updated to standard archs (or cleared out, for automatic arch selection?) Right now we’ve got it set to $(ARCHS_STANDARD_INCLUDING_64_BIT), which may be the problem. I’ll have to give it a shot and see, been a hot second, we use CommonCrypto when building for iOS and OS X.

I suspect you’d be better off linking against Security.framework and building SQLCipher with CommonCrypto as the crypto provider instead of OpenSSL. This is quite a bit simpler than configuring your build to use OpenSSL and you get the benefit of hardware acceleration (an enormous advantage, hard to understate).

For instance, in the sqlcipher.xcodeproj file in the SQLCipher Git repo has an amalgamation target with a Run Script phase that sets the build up for CommonCrypto:

./configure --enable-tempstore=yes --with-crypto-lib=commoncrypto CFLAGS="-DSQLITE_HAS_CODEC -DSQLITE_TEMP_STORE=2"
make sqlite3.c
exit 0

The sqlcipher target links against Security.framework accordingly.


#3

Wow - that solves it. I had no idea I could use commoncrypto. The instructions at github only discuss getting openssl built. Very happy to get rid of that messy part of my build.

Thanks!


#4

Yeah, ironically it’s OpenSSL that’s more widely available to folks on Unix-like systems but it can also be a lot harder to work with configuration-wise. Might be time we took the OpenSSL bits out of the iOS integration tutorial now that we’ve switched the project file over.

There are three crypto providers currently available: openssl, commoncrypto, and libtomcrypt.