3. 编译环境搭建：交叉编译工具链配置与工程组织

说实话，做嵌入式密码库裁剪，最让我头疼的往往不是算法本身，而是编译环境。工具链配不对，后面全是白搭。我见过太多人花了两周移植算法，结果发现编译器选项没设对，整个库跑起来性能还不如桌面版本的一半。

这一章，咱们就把交叉编译环境彻底捋清楚。ARM GCC、RISC-V GCC怎么配，CMake和Makefile怎么组织，静态库和动态库到底选哪个——这些坑我基本都踩过，今天一并说透。

3.1 交叉编译工具链的选择与安装

交叉编译，说白了就是在一台x86的电脑上，编译出能在ARM或RISC-V芯片上跑的代码。工具链的选择，直接决定了你后面能不能顺利干活。

3.1.1 ARM GCC 工具链

ARM平台目前最主流的是arm-none-eabi-gcc，适用于裸机或RTOS环境。如果你跑的是Linux，那就用arm-linux-gnueabihf-gcc。我个人习惯用ARM官方提供的GNU Arm Embedded Toolchain，下载解压就能用，省心。

# 下载ARM GCC 12.2版本
wget https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz

# 解压到指定目录
tar -xf arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt/

# 配置环境变量
export PATH=/opt/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin:$PATH

# 验证安装
arm-none-eabi-gcc --version

3.1.2 RISC-V GCC 工具链

RISC-V这两年发展很快。我最早接触RISC-V是在一个IoT项目上，当时芯片手册都还是草稿版，工具链更是得自己从源码编译。现在好多了，SiFive和芯来科技都提供了预编译好的工具链。

常用的RISC-V工具链分两种：

• riscv64-unknown-elf-gcc：裸机开发，适合RTOS或bare-metal
• riscv64-unknown-linux-gnu-gcc：带Linux系统调用支持

3.2 CMake/Makefile 工程组织

工程组织这块，我见过两种极端：一种是所有代码塞一个文件，另一种是目录嵌套七八层，连自己都找不到头文件。密码库裁剪这种项目，我推荐用CMake做顶层构建，配合Makefile做底层细节控制。

3.2.1 使用CMake管理交叉编译

CMake的好处是跨平台，而且可以通过toolchain文件来切换不同的编译器。我一般会写一个 arm-toolchain.cmake 文件：

# arm-toolchain.cmake
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(TOOLCHAIN_PATH /opt/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi)
set(CMAKE_C_COMPILER ${TOOLCHAIN_PATH}/bin/arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PATH}/bin/arm-none-eabi-g++)

set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN_PATH})
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

# 针对密码库的优化选项
set(CMAKE_C_FLAGS "-mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Os -ffunction-sections -fdata-sections")
set(CMAKE_EXE_LINKER_FLAGS "-Wl,--gc-sections -Wl,-Map=output.map")

然后在项目根目录的 CMakeLists.txt 里这样引用：

cmake_minimum_required(VERSION 3.20)
project(crypto_lib C ASM)

# 设置工具链
set(CMAKE_TOOLCHAIN_FILE ${CMAKE_SOURCE_DIR}/cmake/arm-toolchain.cmake)

# 添加源文件
add_library(crypto_core STATIC
    src/aes/aes_core.c
    src/sha/sha256.c
    src/ecc/ecc_curve.c
    src/random/trng.c
)

# 设置头文件路径
target_include_directories(crypto_core PUBLIC
    ${CMAKE_SOURCE_DIR}/include
    ${CMAKE_SOURCE_DIR}/include/internal
)

# 编译选项
target_compile_definitions(crypto_core PRIVATE
    PLATFORM_EMBEDDED
    CRYPTO_SMALL_FOOTPRINT
)

mkdir build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/arm-toolchain.cmake
make -j4

3.2.2 Makefile 直接管理（适合小型项目）

有时候项目很小，或者CMake版本太老，直接用Makefile反而更灵活。我早期做的一个密码协处理器项目，就是用纯Makefile管理的。这里给一个模板：

# 工具链定义
CROSS_COMPILE ?= arm-none-eabi-
CC = $(CROSS_COMPILE)gcc
AR = $(CROSS_COMPILE)ar
SIZE = $(CROSS_COMPILE)size

# 目标架构
ARCH_FLAGS = -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16

# 编译选项
CFLAGS = $(ARCH_FLAGS) -Os -g -ffunction-sections -fdata-sections
CFLAGS += -I./include -I./include/internal
CFLAGS += -DPLATFORM_EMBEDDED -DCRYPTO_SMALL_FOOTPRINT

# 源文件
SRCS = src/aes/aes_core.c \
       src/sha/sha256.c \
       src/ecc/ecc_curve.c \
       src/random/trng.c

OBJS = $(SRCS:.c=.o)

# 目标：静态库
libcrypto.a: $(OBJS)
	$(AR) rcs $@ $^
	$(SIZE) $@

# 编译规则
%.o: %.c
	$(CC) $(CFLAGS) -c $< -o $@

# 清理
clean:
	rm -f $(OBJS) libcrypto.a

3.3 静态库与动态库的编译策略

这个问题，我在不同项目里反复纠结过。静态库和动态库，在受限环境下的选择逻辑和桌面开发完全不同。

3.4 本章知识体系总览

下面这张图，把本章的核心逻辑串起来了。从工具链选择，到工程组织，再到库类型决策，每一步都有对应的考量。

3.5 避坑指南：我踩过的几个坑

• 工具链版本不匹配：ARM GCC的9.x和12.x生成的代码，在浮点运算上行为有差异。我有个项目从10.x升级到12.x后，AES的查表实现性能下降了15%，后来发现是编译器自动向量化策略变了。建议锁定工具链版本，不要轻易升级。
• 链接顺序问题：在Makefile里，静态库的链接顺序很重要。我曾经把 -lcrypto 放在源文件前面，结果链接器报了一堆未定义引用。记住：库要放在引用它的目标文件后面。
• 调试信息膨胀：交叉编译时，如果忘了加 -g 选项，出问题没法调试；但如果加了 -g 又忘了 -Os，生成的库可能比目标芯片的Flash还大。我一般调试阶段用 -Og -g，发布阶段用 -Os -g0。