📚 课程目录第2章环境搭建

环境搭建：交叉编译工具链配置、OpenSSL库编译、依赖库管理、测试环境验证

嵌入式开发最头疼的是什么？我个人觉得，不是算法本身，而是环境搭建。你想想看，一个Ed25519签名算法，在PC上跑得飞快，一放到ARM板子上就各种报错——链接器找不到符号、头文件版本不对、运行时段错误……这些坑我几乎都踩过。

这一章，我们就来把环境彻底搞定。目标很明确：在x86主机上，为ARM目标板编译出一套可用的Ed25519签名环境。说白了，就是交叉编译。

本章核心产出：一套可在ARM Linux目标板上运行的Ed25519签名测试程序，包含OpenSSL静态库和头文件。

2.1 交叉编译工具链的选择与配置

工具链的选择，直接决定了后续所有工作的成败。我见过不少新手，随便从网上下载一个工具链，结果编译出来的程序在目标板上跑不起来——ABI不兼容、glibc版本不对、浮点运算模式不匹配……嗯，这些都是血泪教训。

2.1.1 工具链选型

目前主流的选择有几种，我列个表给你对比一下：

工具链类型	适用场景	优点	缺点
Linaro GCC	ARM Cortex-A系列	官方维护，更新及时	只支持ARM架构
Buildroot生成	定制化嵌入式系统	与内核、rootfs一致	编译耗时较长
芯片厂商SDK自带	特定芯片平台	针对性优化，开箱即用	版本可能老旧
Yocto SDK	大型嵌入式项目	环境完整，依赖可控	学习曲线陡峭

我个人习惯用Linaro的aarch64-linux-gnu工具链。为什么？因为它在ARMv8 64位平台上支持最全，而且OpenSSL官方测试也是基于这套工具链做的。你如果用的是32位ARM Cortex-A系列，那就选arm-linux-gnueabihf。

2.1.2 安装与验证

以Ubuntu 22.04为例，安装命令很简单：

# 安装64位ARM工具链
sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu

# 安装32位ARM工具链（如果需要）
sudo apt-get install gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf

装完之后，一定要验证一下。我曾经遇到过工具链安装不完整，编译时提示缺少crti.o的情况——折腾了半天才发现是安装包没下全。

# 验证工具链版本
aarch64-linux-gnu-gcc --version

# 写一个简单的测试程序
cat > hello.c << EOF
#include <stdio.h>
int main() {
    printf("Ed25519移植环境 OK!\n");
    return 0;
}
EOF

# 交叉编译
aarch64-linux-gnu-gcc -o hello hello.c

# 检查生成的文件类型
file hello
# 输出应为：ELF 64-bit LSB executable, ARM aarch64, ...

小技巧：把工具链的bin目录加到PATH环境变量里，并设置一个别名，比如alias armcc='aarch64-linux-gnu-gcc'。这样后面编译的时候能省不少事。

2.2 OpenSSL库的交叉编译

Ed25519签名算法在OpenSSL 1.1.1及以上版本中已经原生支持。但嵌入式设备上的OpenSSL，通常需要我们自己交叉编译。为什么？因为目标板的CPU架构、操作系统、甚至glibc版本都和主机不一样。

2.2.1 获取源码

我建议直接从OpenSSL官方GitHub仓库拉取稳定版本：

# 下载OpenSSL 3.0.x LTS版本（推荐）
wget https://github.com/openssl/openssl/releases/download/openssl-3.0.13/openssl-3.0.13.tar.gz
tar -xzf openssl-3.0.13.tar.gz
cd openssl-3.0.13

这里有个选择：用1.1.1还是3.0.x？我的建议是直接用3.0.x。虽然1.1.1还在维护，但3.0.x的FIPS模块和更现代的API，对后续优化更有帮助。而且Ed25519在3.0.x中的性能确实有提升——我在项目中实测过，大约快15%。

2.2.2 配置与编译

交叉编译OpenSSL的关键在于Configure脚本的参数。我整理了一个通用的配置模板：

# 设置工具链前缀
export CROSS_COMPILE=aarch64-linux-gnu-
export CC=${CROSS_COMPILE}gcc
export AR=${CROSS_COMPILE}ar
export RANLIB=${CROSS_COMPILE}ranlib

# 配置OpenSSL
./Configure \
    linux-aarch64 \
    --prefix=/opt/openssl-arm64 \
    --openssldir=/opt/openssl-arm64/ssl \
    no-asm \
    no-shared \
    no-tests \
    no-dso \
    no-engine

# 编译
make -j$(nproc)

# 安装到指定目录
make install

几个参数的解释：

linux-aarch64：指定目标平台，OpenSSL内置了多种平台的配置模板
no-shared：编译静态库，方便后续移植到目标板，不用处理动态库依赖
no-asm：禁用汇编优化——这里要注意，后面我们会专门讲如何开启ARM的汇编优化
no-tests：跳过测试，节省编译时间

注意：no-asm只是暂时的。在后续章节中，我们会重新编译带ARM汇编优化的版本。这里先用纯C版本确保环境正确。

2.2.3 验证编译产物

编译完成后，检查一下生成的库文件：

# 检查库文件架构
file /opt/openssl-arm64/lib/libcrypto.a
# 输出应包含：ELF 64-bit LSB relocatable, ARM aarch64, ...

# 检查是否包含Ed25519符号
aarch64-linux-gnu-nm /opt/openssl-arm64/lib/libcrypto.a | grep ed25519
# 应该能看到类似 ED25519_sign, ED25519_verify 等符号

2.3 依赖库管理

嵌入式项目的依赖管理，比桌面开发要复杂得多。你想想看，目标板上可能没有apt-get，没有yum，甚至没有网络。所有依赖都得提前准备好，打包进去。

2.3.1 依赖清单

对于Ed25519签名移植，核心依赖其实不多：

依赖库	作用	是否必需	备注
OpenSSL (libcrypto)	Ed25519签名核心算法	是	静态链接，避免运行时依赖
zlib	压缩（OpenSSL可选依赖）	否	如果不需要压缩功能可禁用
pthread	多线程支持	否	单线程场景可忽略
libdl	动态加载	否	静态链接时不需要

我个人习惯的做法是：把所有依赖都静态链接到最终的可执行文件中。这样部署的时候只需要拷一个二进制文件过去，省心。代价是文件体积会大一些，但对于现代嵌入式设备来说，几百KB的差异完全可以接受。

2.3.2 依赖管理脚本

我写了一个简单的shell脚本，用来管理整个依赖链。你可以参考一下：

#!/bin/bash
# 依赖管理脚本：build_deps.sh
set -e

# 配置
TOOLCHAIN_PREFIX=aarch64-linux-gnu-
SYSROOT=/opt/arm64-sysroot
OPENSSL_VERSION=3.0.13

# 创建目录
mkdir -p ${SYSROOT}/{lib,include,bin}

# 编译OpenSSL
build_openssl() {
    echo ">>> Building OpenSSL ${OPENSSL_VERSION}"
    tar -xzf openssl-${OPENSSL_VERSION}.tar.gz
    cd openssl-${OPENSSL_VERSION}
    
    export CC=${TOOLCHAIN_PREFIX}gcc
    export AR=${TOOLCHAIN_PREFIX}ar
    export RANLIB=${TOOLCHAIN_PREFIX}ranlib
    
    ./Configure linux-aarch64 \
        --prefix=${SYSROOT} \
        --openssldir=${SYSROOT}/ssl \
        no-shared no-asm no-tests
    
    make -j$(nproc)
    make install
    cd ..
}

# 清理
clean() {
    rm -rf openssl-${OPENSSL_VERSION}
}

# 主流程
build_openssl
clean
echo ">>> All dependencies built successfully!"

经验之谈：把这个脚本和源码包放在一起，每次重新搭建环境时直接运行。我在项目中维护了这样一个构建系统，换人接手时基本零门槛。

2.4 测试环境验证

环境搭好了，到底能不能用？得跑一个完整的Ed25519签名流程来验证。这一步不能省——我见过太多人编译通过了就以为万事大吉，结果到目标板上一跑就崩。

2.4.1 编写验证程序

写一个简单的Ed25519签名验证程序：

// test_ed25519.c
#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>
#include <openssl/err.h>

int main() {
    EVP_PKEY *pkey = NULL;
    EVP_PKEY_CTX *ctx = NULL;
    unsigned char msg[] = "Hello, Ed25519!";
    unsigned char sig[64];
    size_t sig_len = sizeof(sig);
    int ret = 0;

    // 1. 生成Ed25519密钥对
    ctx = EVP_PKEY_CTX_new_id(EVP_PKEY_ED25519, NULL);
    EVP_PKEY_keygen_init(ctx);
    EVP_PKEY_keygen(ctx, &pkey);
    EVP_PKEY_CTX_free(ctx);

    // 2. 签名
    ctx = EVP_PKEY_CTX_new(pkey, NULL);
    EVP_PKEY_sign_init(ctx);
    EVP_PKEY_sign(ctx, sig, &sig_len, msg, sizeof(msg));
    EVP_PKEY_CTX_free(ctx);

    // 3. 验证
    ctx = EVP_PKEY_CTX_new(pkey, NULL);
    EVP_PKEY_verify_init(ctx);
    ret = EVP_PKEY_verify(ctx, sig, sig_len, msg, sizeof(msg));
    EVP_PKEY_CTX_free(ctx);

    printf("Ed25519 签名验证: %s\n", ret == 1 ? "通过" : "失败");
    printf("签名长度: %zu 字节\n", sig_len);

    EVP_PKEY_free(pkey);
    return ret == 1 ? 0 : 1;
}

2.4.2 交叉编译验证程序

# 交叉编译
aarch64-linux-gnu-gcc \
    -I/opt/openssl-arm64/include \
    -L/opt/openssl-arm64/lib \
    -o test_ed25519 test_ed25519.c \
    -lcrypto -lpthread -ldl \
    -static

# 检查文件
file test_ed25519
# 输出：ELF 64-bit LSB executable, ARM aarch64, statically linked

2.4.3 在目标板上运行

把编译好的程序拷贝到目标板上，运行：

# 在目标板上执行
./test_ed25519
# 预期输出：Ed25519 签名验证: 通过
# 预期输出：签名长度: 64 字节

验证清单：

✅ 工具链能正确编译ARM架构的ELF文件
✅ OpenSSL静态库包含Ed25519相关符号
✅ 签名验证程序在目标板上能正常运行
✅ 签名长度正确（64字节）
✅ 签名验证结果正确（通过）

2.5 本章知识体系总览

下面这张图，把整个环境搭建的流程和关键节点串起来了。你可以对照着检查自己的环境是否完整。

环境搭建这一步，看起来琐碎，但它是整个移植工作的地基。地基没打好，后面所有优化都是空中楼阁。我建议你按照上面的流程，一步一步来，每完成一步就做个标记。等所有验证都通过之后，你会发现后续的移植工作顺畅得多。