Question regarding SQLCipher and clang

75 views
Skip to first unread message

Werner Dittmann

unread,
Jul 11, 2016, 12:47:35 PM7/11/16
to SQLCipher Users
Maybe this was already asked, however I searched for it, no info found so far.

With Android NDK 11 and newer Google deprecated GCC and now favours Clang. Because our application uses NDK and SQLCipher together my question: is there some official support or ready-to-go build for SQLCipher that uses Clang? If not, is it planned?


Regards,

Werner

Nick Parker

unread,
Jul 12, 2016, 9:13:02 AM7/12/16
to 'Werner Dittmann' via SQLCipher Users
> --
>
> ---
> 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.

SQLCipher for Android uses the default configuration from the Android
NDK. Specifically, we utilize the make-standalone-toolchain.sh for
building the OpenSSL dependency, other portions of the NDK build
utilize defaults. NDK_TOOLCHAIN_VERSION is overridden set in the
Application.mk file, but this is something you could adjust with your
own build.

--
Nick Parker

Werner Dittmann

unread,
Jul 12, 2016, 10:22:49 AM7/12/16
to SQLCipher Users
Hi Nikc,

thanks for the fast reply. I checked the build scripts and saw in the oppenSSL buildscript
that you explicitly set 'CC=arm-linux-androideabi-gcc'
in this script.

If I would use the Clang in all other build scripts would this work? In general clang is ABI compatible with GCC, don't know if this true also for Android (I believe it is :-) ). Thus
mixing GCC and Clang objects/libraries shouldn't be an issue. 

I'll try to build SQLCipher using Clang and openSSL using its unmodified build script, thus with GCC and check if it build/works. Another test would be to change the openSSL
build script to also use Clang, maybe this would be even better than a mix of compilers.

Nick Parker

unread,
Jul 12, 2016, 11:01:23 AM7/12/16
to 'Werner Dittmann' via SQLCipher Users
On 07/12, 'Werner Dittmann' via SQLCipher Users wrote:
> Hi Nikc,
>
> thanks for the fast reply. I checked the build scripts and saw in the
> oppenSSL buildscript
> that you explicitly set 'CC=arm-linux-androideabi-gcc'
> in this script.

Ah, that is correct, I forgot about that part! The OpenSSL build
script would need updates in order to utilize Clang directly.

> If I would use the Clang in all other build scripts would this work? In
> general clang is ABI compatible with GCC, don't know if this true also for
> Android (I believe it is :-) ). Thus
> mixing GCC and Clang objects/libraries shouldn't be an issue.

I would not know with out attempting a change and running the test
suite [1].

> I'll try to build SQLCipher using Clang and openSSL using its unmodified
> build script, thus with GCC and check if it build/works. Another test would
> be to change the openSSL
> build script to also use Clang, maybe this would be even better than a mix
> of compilers.

[1] https://github.com/sqlcipher/sqlcipher-android-tests

--
Nick Parker

Werner Dittmann

unread,
Jul 18, 2016, 10:43:30 AM7/18/16
to SQLCipher Users
Hi Nick,

I did a few tests with my application and got some good results and one smaller issue :-) .

To test some stuff I did the following steps:

- added 'NDK_TOOLCHAIN_VERSION := clang' to SQLCipher's Application.mk in jni/
- built the whole code with openSSL, thus first a 'make init', then 'make' to built the rest

Thus openSSL was compiled with GCC, the other SQLCipher C / C++ code with clang. The libraries were
built and I copied them into my application development tree, created my application and tested it - all works well.

I could open and process existing databases created with the older code, also create and process new 
databases with this newly built libraries. Thus the GCC and Clang code seems to work together without
issues. Also my own C/C++ code was compiled with GCC and work with the Clang compiled code of
SQLCipher. I haven't run the official tests (see [1] in your posting), just tested with my application.

I then tried to build openSSL with clang and found an issue with the openSSL build/configure scripts. 

To check if I can build openSSL with clang I modified the 'build-openssl-libraries.sh' file to create the
standalone toolchain with clang:

    ${ANDROID_NDK_ROOT}/build/tools/make-standalone-toolchain.sh \
        --platform=${ANDROID_PLATFORM_VERSION} \
        --install-dir=${ANDROID_TOOLCHAIN_DIR} \
        --arch=arm \
        --toolchain=arm-linux-androideabi-clang

I also tested the newer python based command file:
    ${ANDROID_NDK_ROOT}/build/tools/make_standalone_toolchain.py  --install-dir=${ANDROID_TOOLCHAIN_DIR) --arch=arm

The new command works well and created the standalone toolchain without any issues.

Then I changed CC=arm-linux-androideabi-gcc to CC=arm-linux-androideabi-clang and started the build. The openSSL
compile bails out because the openSSL build script uses a compiler flag '-mandroid' that clang does not understand/support. I have not modified
the openSSL scripts, they are always loaded before building openSSL. IMHO here the openSSL team needs to change the build script to
have clang compliant build.

Werner

Am Dienstag, 12. Juli 2016 17:01:23 UTC+2 schrieb Nick Parker:
On 07/12, 'Werner Dittmann' via SQLCipher Users wrote:
 
<SNIP --- SNAP>

Nick Parker

unread,
Jul 18, 2016, 3:08:09 PM7/18/16
to Werner Dittmann

Hello Werner,

Thank you for sharing your feedback. From a support perspective, we would prefer not to ship binaries that used mixed compilers. This is certainly something we would consider if OpenSSL makes changes in the future that facilitate a change. Thanks!

Nick Parker


On 18 Jul 2016, at 9:43, 'Werner Dittmann' via SQLCipher Users wrote:

Hi Nick,

I did a few tests with my application and got some good results and one
smaller issue :-) .

To test some stuff I did the following steps:

  • added 'NDK_TOOLCHAIN_VERSION := clang' to SQLCipher's Application.mk in jni/

--


Reply all
Reply to author
Forward
0 new messages