交叉编译sqlcipher

1. 小心预编译宏SQLITE_HAS_CODEC

2. openssl在不同License下，导出的符号不对等。

一如往常，所有GNU Make like的项目在linux平台下configure+make顺利编译安装，但交叉编译到android linux平台时，过程总是问题不断，要一个一个去手动解决。

1. 小心预编译宏SQLITE_HAS_CODEC

sqlcipher是sqlite3的加强版，提供加密。也就是sqlite3的修改版，里面修改添加了代码，并以一些预编译宏来进行分支选路。所有修改过的代码片段都包含在预编译宏SQLITE_HAS_CODEC保护下。如果你没有加入这个预编译宏SQLITE_HAS_CODEC，这部分代码就不会包含在源文件中。必须要清楚，这部分代码是修改，不是新添加。对于不包含新添加还晓幸编译出一个原版，但是不包含修改在代码，就连原本必要定义的结构或代码都不包含了，所以编译就会报错N多东西没有定义。而这些东西却在源文件文本中。

2. openssl在不同License下，导出的符号不对等。

在你的linux操作系统，你使用的openssl-devel包都在[GNU Public License]下，几乎所有依赖openssl的项目都可以很好地兼容编译。但是你要清楚，当你下载openssl代码包编译出来的库，却是[OpenSSL license]。这两个License有什么不同，就不深入了，但却影响我们的编译兼容。

左图是[OpenSSL License]下的hmac.h

右图是[GNU Public License]下的hmac.h，也就是我们在linux操作系统常用的openssl-devel包。

在[GNU Public License]下的hmac.h中，结构体hmac_ctx_st导出到头文件。

而[OpenSSL License]下的hmac.h中， 结构体hmac_ctx_st却要隐藏定义，用户必须通过HMAC_CTX_new()来动态分配空间。

这有什么大影响呢？问题是一些项目在它们的结构体直接聚合hmac_ctx_st结构体，使得你编译这些项目时不兼容。

例如sqlcipher项目这样的代码段

这就让你闷，在[GNU Public License]的openssl包可以编译过，在[OpenSSL License]的openssl库就编译不过。

这个结构体的定义在

 又要手动在这添加在那添加了。

交叉编译sqlcipher

标签：sqlite3   gnu   image   使用   分支   项目   结构体   导出   ima