📚 课程目录第3章开发环境搭建（C/C++）

3. 开发环境搭建（C/C++）

聊到加密SDK的C/C++环境，我最常听到的一句话就是：“不就是装个编译器吗？”
嗯，要是真这么简单，我当年也不会被链接错误折腾一整天。

加密SDK底层依赖很多系统级的东西——OpenSSL、线程库、平台运行时。
随便一个版本不对，加密函数就崩给你看。所以今天咱们把这个过程拆明白。

3.1 编译器与构建工具选择

我个人习惯用 GCC 9.3+ 或 Clang 12+，Windows 上就 MSVC 2022。
为什么？因为主流加密库（比如 OpenSSL 1.1.1 / 3.0）的最低要求就卡在这儿。

平台	推荐编译器	最低版本
Linux	GCC	9.3
macOS	Clang	12.0
Windows	MSVC	2022 (v143)

一个小技巧： 别追最新版。我在项目中曾用 GCC 12 编译 OpenSSL 3.0，结果因为 LTO 行为变更搞出一堆汇编冲突。老老实实用 LTS 版本吧。

构建工具我建议 CMake 3.20+。你想想看，现代加密SDK几乎都用 CMake 做跨平台构建。
就算没有自带 CMakeLists.txt，自己写一个也很快。

3.2 依赖库准备

C/C++ 加密SDK的大部分功能依赖底层密码库。最常见的是 OpenSSL 和 BoringSSL。

核心依赖清单：

OpenSSL（libcrypto, libssl）—— 对称/非对称加密、证书、哈希
zlib —— 压缩，部分协议握手需要
pthread（Linux）/ WinThreads（Windows）—— 线程安全锁

怎么装？我直接推荐两种方式：

系统包管理器 —— 省心，但不一定是最新版
源码编译+本地安装 —— 可控，适合定制

曾经为了一个 FIPS 合规项目，我们被迫从源码编译 OpenSSL 并打上特定补丁。那段时间我对 ./config 参数倒背如流……

Linux 上快速安装 OpenSSL

sudo apt-get install libssl-dev   # Ubuntu/Debian
sudo yum install openssl-devel    # CentOS/RHEL

macOS 上使用 Homebrew

brew install openssl
# 注意：Homebrew 默认不链接，需要手动设置 PKG_CONFIG_PATH
export PKG_CONFIG_PATH="/usr/local/opt/openssl/lib/pkgconfig"

Windows 上使用 vcpkg

vcpkg install openssl-windows:x64-windows
# 集成到 CMake：
cmake -B build -DCMAKE_TOOLCHAIN_FILE=[vcpkg_root]/scripts/buildsystems/vcpkg.cmake

重要警告： 永远不要在项目中混装多个 OpenSSL 版本。
我曾经接手过一个项目，系统自带的 1.0.2 和手动编译的 1.1.1 同时被链接，结果内存泄漏查了三天。

3.3 编译选项与链接

加密SDK敏感度高，编译选项直接影响安全性。我个人一定会加上这些：

-fPIC（Linux/macOS）—— 生成位置无关代码，否则动态库加载会崩
-O2 或 -O3 —— 加密运算密集，优化不能省
-D_FORTIFY_SOURCE=2 —— 缓冲区溢出保护
-Wl,-z,now,-z,relro —— 延迟绑定 + 只读重定位，防 GOT 覆写

链接时注意顺序：
-lssl -lcrypto -lz -lpthread。
为什么？因为链接器是单次扫描，被依赖的库要放在后面。顺序不对就是“未定义引用”。

3.4 目录结构与构建示例

我习惯的 SDK 项目结构长这样：

my_sdk/
├── CMakeLists.txt
├── include/
│   └── my_sdk/
│       ├── core.h
│       └── crypto.h
├── src/
│   ├── core.cpp
│   └── crypto.cpp
├── third_party/     # 或者外部依赖通过 vcpkg 管理
└── tests/
    └── test_crypto.cpp

一个能用的 CMakeLists.txt 示例：

cmake_minimum_required(VERSION 3.20)
project(MyCryptoSDK VERSION 1.0.0 LANGUAGES C CXX)

find_package(OpenSSL REQUIRED)
find_package(ZLIB REQUIRED)

add_library(my_sdk SHARED
    src/core.cpp
    src/crypto.cpp
)

target_include_directories(my_sdk
    PUBLIC include
    PRIVATE ${OPENSSL_INCLUDE_DIR} ${ZLIB_INCLUDE_DIRS}
)

target_link_libraries(my_sdk
    PUBLIC OpenSSL::SSL OpenSSL::Crypto
    PRIVATE ZLIB::ZLIB
)

# 启用安全编译选项
target_compile_options(my_sdk PRIVATE -O2 -D_FORTIFY_SOURCE=2)
if(UNIX)
    target_link_options(my_sdk PRIVATE -Wl,-z,now,-z,relro)
endif()

3.5 验证环境是否就绪

全部配好后，写个最小测试程序跑一下：

#include <openssl/evp.h>
#include <iostream>

int main() {
    std::cout << "OpenSSL version: " << OpenSSL_version(OPENSSL_VERSION) << std::endl;
    std::cout << "SDK env OK!" << std::endl;
    return 0;
}

编译并运行：

g++ -o test test.cpp -lssl -lcrypto
./test
# 输出：OpenSSL version: OpenSSL 3.0.12 ...

我个人建议把这句放到单元测试的 SetUp 里。我之前在某个项目中，就是因为开发机环境没问题，但 Jenkins 上的 OpenSSL 版本不同，结果签名算法返回空指针。那种错误最难查。

3.6 跨平台注意事项

有几点你得特别留心：

路径分隔符 —— 别写死 /，用 CMake 的 ${CMAKE_BINARY_DIR} 或 filesystem::path
动态库后缀 —— .so（Linux）、.dylib（macOS）、.dll（Windows）
线程模型 —— Linux 用 pthread，Windows 用 SRWLock，macOS 用 os_unfair_lock。封装一层平台抽象

实战建议： 在 CMakeLists.txt 里用 CMAKE_SYSTEM_NAME 做条件判断，对不同平台设置不同的链接库。我见过太多把 Windows 路径硬编码到 Linux 项目里的例子了。

3.7 避坑总结

别混装多版本 OpenSSL —— 用 vcpkg 或 conan 统一管理
链接顺序不能错 —— 被依赖的库放最后
安全选项别忘了 —— -D_FORTIFY_SOURCE=2 加在 Release 模式
测试环境与生产环境一致 —— 我曾在 CI 容器里用 Ubuntu 20.04，部署到 CentOS 7，结果 glibc 版本不兼容，所有加密函数直接段错误。从那以后我坚持用 Docker 固定运行环境

嗯，环境搭建这部分其实不难，但细节特别多。多花十分钟把 CMake 脚本写完整，后面能少掉三天头发。