Can't run sqlcipher "shell" under Mac OS-X Mavericks

[Eli]

I get a dynamic link error every time I try to run the sqlcipher tool under MacOS Mavericks.  It builds fine, but as soon as I try to do anything encryption related when using "sqlcipher" I'll get a dyld error.

The symbols not found are kSecRandomDefault, and SecRandomCopyBytes.  How can I ensure that these are statically linked into the sqlcipher binary, and/or how can I resolve the dynamic linking error at runtime?

Thanks!

Here's an example of the problem:

/usr/local/bin/sqlcipher newlawbook.db 

SQLCipher version 3.8.4.3 2014-04-03 16:53:12

Enter ".help" for instructions

Enter SQL statements terminated with a ";"

sqlite> ATTACH DATABASE 'out.encdb' as encrypted key '123';             

sqlite> SELECT sqlcipher_export('encrypted'); 

dyld: lazy symbol binding failed: Symbol not found: _SecRandomCopyBytes

  Referenced from: /usr/local/lib/libsqlcipher.0.dylib

  Expected in: flat namespace

dyld: Symbol not found: _SecRandomCopyBytes

  Referenced from: /usr/local/lib/libsqlcipher.0.dylib

  Expected in: flat namespace

Trace/BPT trap

[William Gray]

Hi Eli,

Are you linking against Security.framework in your build? That sounds like the most likely cause of the missing symbol issues.

Cheers,

Billy

--

---
You received this message because you are subscribed to the Google Groups "SQLCipher Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sqlcipher+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eli]

How do I link against the security framework from the command line?  This is for the command-line "sqlcipher" tool.

[Eli]

I did try adding "-framework Security" to the Makefile for sqlcipher and doing a make clean and rebuilding but ran into the same problem.

Also is there a way to build the sqlcipher executable from the xcodeproject?  All I see being build from there is libsqlcipher.a

Thanks,

-Eli

[William Gray]

Well, I think you'd want to include it in LDFLAGS on configure, for example, something like:

./configure --with-crypto-lib=commoncrypto --enable-tempstore=yes CFLAGS="-DSQLITE_HAS_CODEC" LDFLAGS="-framework Security"

Does that help?

[Eli]

No, I get the same runtime dynamic link error when I do that.

[Eli]

OK, I tracked down what's going on and manually did a quick fix so I can build sqlcipher.  Maybe someone knows a proper fix -- I'll look into it more when I have more time.

To help with tracking this down I turned off shared libraries with "--enable-shared=no", which caused me to get the link error at build time rather than waiting until run time.

Here's the link error:

./libtool --mode=link gcc   -DSQLITE_HAS_CODEC -framework Security -DSQLCIPHER_CRYPTO_CC -DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG   -DSQLITE_THREADSAFE=1 -DSQLITE_OMIT_LOAD_EXTENSION=1   -framework Security  -DHAVE_READLINE=0  \

-o sqlcipher ./src/shell.c libsqlcipher.la \

-framework Security  -rpath "/usr/local/lib"

libtool: link: gcc -DSQLITE_HAS_CODEC -DSQLCIPHER_CRYPTO_CC -DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=0 -o sqlcipher ./src/shell.c  ./.libs/libsqlcipher.a

Undefined symbols for architecture x86_64:

  "_SecRandomCopyBytes", referenced from:

      _sqlcipher_cc_random in libsqlcipher.a(sqlite3.o)

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

make: *** [sqlcipher] Error 1

Rather than the sqlcipher/sqlite makefile invoking gcc directly it invokes a shell script "./libtool" to do the build.  I had been sprinkling "-framework Security" throughout to try to get it to build properly, and you'll see that libtool is actually passed "-framework Security" twice, however when libtool actually invokes gcc, the "-framework Security" switch has been dropped from the command line:

 

libtool: link: gcc -DSQLITE_HAS_CODEC -DSQLCIPHER_CRYPTO_CC -DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=0 -o sqlcipher ./src/shell.c  ./.libs/libsqlcipher.a

I manually copied the line that libtool was using to invoke gcc and added back "-framework Security" which successfully built the sqlcipher executable - no more undefined symbols, and it appears to be working properly.

% gcc -framework Security -DSQLITE_HAS_CODEC -DSQLCIPHER_CRYPTO_CC -DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H -DBUILD_sqlite -DNDEBUG -DSQLITE_THREADSAFE=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=0 -o sqlcipher ./src/shell.c  ./.libs/libsqlcipher.a

 

Since libtool was stripping that option, the "sqlcipher" binary shouldn't be working for anyone doing builds on OSX - at least not for command-line builds.  Hopefully the folks at Zetetic can put in a nice fix in for this.  (If I missed a ./configure switch that will already make this work, please let me know!)

-Eli