VS C++项目中64位SQLite3（带sqlite_has_codec）编译链接错误排查

遇到这种32位编译正常、64位却爆出一堆未解析外部符号（比如_EVP_CIPHER_key_length）的情况，我之前也踩过类似的坑，大概率是依赖库位数不匹配或者编译配置的细节没跟上，下面是几个你可以逐一排查的方向：

• 检查OpenSSL库的位数匹配性
  _EVP_CIPHER_key_length是OpenSSL库中的函数，你32位编译正常说明32位的OpenSSL库配置没问题，但64位编译时极有可能链接了32位版本的OpenSSL库，或者根本没指定正确的64位库路径。请确认：

  • 链接器的「附加依赖项」中，OpenSSL的库文件（比如64位版本通常是libeay64.lib或对应版本命名的库）是64位专属的；
  • 链接器的「附加库目录」指向的是64位OpenSSL库所在的文件夹，而非32位库的路径。

• 确认sqlite3的编译/配置选项
  如果你的sqlite3.c是自行编译的，要检查64位编译时是否启用了需要OpenSSL支持的宏（比如SQLITE_HAS_CODEC，用于sqlite3的加密功能）。32位编译时你可能已经正确定义了该宏，但64位配置中遗漏了，导致sqlite3在64位编译时尝试调用OpenSSL函数却没找到对应的库链接。

• 核对CppSqlite3的编译配置一致性
  确保CppSqlite3.cpp在64位编译时，和sqlite3、OpenSSL的预处理器宏定义完全一致。比如是否定义了SQLITE_USE_URI、SQLITE_THREADSAFE等相同的宏，避免因宏定义差异导致链接时符号不匹配。

• 检查extern "C"包裹是否正确
  因为sqlite3和OpenSSL都是C语言实现的库，在C项目中引用时必须用extern "C"包裹头文件，否则64位编译时C编译器会对符号进行名字修饰，导致找不到对应的C风格符号。确认你的代码中是否有类似这样的包裹：

  extern "C" {
  #include "sqlite3.h"
  #include <openssl/evp.h>
  }
  

• 清理重建项目
  有时候项目的中间生成文件（比如.obj、.lib）会有缓存，32位编译的残留文件可能干扰64位编译。尝试清理整个项目的生成目录，然后重新进行64位编译，排除缓存导致的问题。

内容的提问来源于stack exchange，提问作者hugo411