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