电子商务网站调研,如何创建自己的卡网,长沙包装设计公司排名,拉一条宽带要多少钱嵌入式开发必备#xff1a;手把手教你配置ARM交叉编译工具链#xff08;含常见问题排查#xff09; 如果你在嵌入式开发中遇到过这样的场景#xff1a;在性能强劲的x86开发机上写代码#xff0c;却要生成能在资源受限的ARM设备上运行的程序#xff0c;那么交叉编译就是你…嵌入式开发必备手把手教你配置ARM交叉编译工具链含常见问题排查如果你在嵌入式开发中遇到过这样的场景在性能强劲的x86开发机上写代码却要生成能在资源受限的ARM设备上运行的程序那么交叉编译就是你绕不开的核心技能。这不仅仅是“换个编译器”那么简单它涉及到工具链的选择、环境变量的配置、库文件的路径设置以及一系列令人头疼的编译错误。很多开发者初次接触时往往被arm-linux-gnueabihf-gcc这类看似复杂的名字吓退或者在配置环境时陷入“库找不到”、“链接失败”的泥潭。这篇文章将从一个实战项目开发者的视角出发带你彻底搞懂ARM交叉编译工具链。我们不只讲理论更聚焦于如何落地。我会分享从工具链命名规则解析、环境变量设置、库文件路径配置到编译错误排查的一整套实战经验。无论你是刚接触嵌入式开发的新手还是希望优化现有工作流的老手都能在这里找到可立即上手的解决方案。1. 理解交叉编译为什么你的电脑不能直接编译ARM程序在开始配置之前我们需要先理解交叉编译的本质。简单来说交叉编译就是在一个平台上生成另一个平台可执行代码的过程。这里的“平台”通常指处理器架构如x86、ARM和操作系统如Linux、裸机的组合。为什么嵌入式开发几乎离不开交叉编译原因很现实目标设备资源有限你的嵌入式设备可能只有几十兆内存跑个应用都吃力更别说运行庞大的编译器了。开发效率考量在性能强大的开发机宿主机上编译速度比在目标板上快几个数量级。环境一致性确保所有开发者使用相同的工具链版本避免“在我机器上能编译”的问题。这里需要理解三个关键概念build、host和target。这是理解工具链命名的基石。build构建编译器的平台也就是你正在运行编译命令的机器通常是x86_64的Linux或Windows。host运行编译器的平台。在交叉编译场景下host通常与build相同。target编译器生成代码所运行的平台也就是你的嵌入式设备如ARM Cortex-A53。当这三者都相同时就是本地编译当target与build不同时就是交叉编译。我们配置工具链本质上就是在告诉编译器“我在这里build为你host工作但你要生成能在那里target运行的代码。”2. 解码工具链命名从arm-linux-gnueabihf-gcc说起第一次看到arm-linux-gnueabihf-gcc这种名字可能会觉得它像某种加密语言。其实它的命名遵循着arch-vendor-os-abi的通用规则每个部分都透露着重要信息。2.1 命名规则深度解析让我们拆解一个典型例子arm-linux-gnueabihf-gcc字段示例值含义说明常见可选值archarm目标CPU架构arm,aarch64,mips,riscv,x86_64vendor(空)工具链提供商none无特定厂商,pokyYocto,ti德州仪器oslinux目标操作系统linux,none裸机/无OS,androidabignueabihf应用程序二进制接口gnueabi软浮点,gnueabihf硬浮点,musleabivendor字段有时会被省略但这不影响使用。os字段为none通常意味着为裸机bare-metal环境编译比如运行在Cortex-M系列单片机上的程序没有操作系统支持。ABIApplication Binary Interface是理解工具链差异的关键。它定义了函数调用约定、系统调用方式、数据对齐规则等底层细节。对于ARM架构你需要特别关注浮点运算的支持方式gnueabi使用软件模拟浮点运算软浮点。兼容性最好但性能较差。gnueabihf使用硬件浮点单元硬浮点。性能更好但要求目标CPU支持硬件浮点指令。musleabi使用musl libc库的嵌入式ABI。生成的二进制文件通常更小。提示如果你不确定目标设备是否支持硬件浮点一个简单的判断方法是查看芯片手册或运行cat /proc/cpuinfo。如果看到Features中包含vfpv3或neon通常意味着支持硬浮点。2.2 常见工具链家族与选择指南市面上有多个组织提供ARM工具链各有侧重Linaro GCC由Linaro组织维护针对ARM架构优化更新活跃社区支持好。适合大多数Linux嵌入式开发。# 典型的Linaro工具链命名 arm-linux-gnueabihf-gcc # ARMv7硬浮点32位 aarch64-linux-gnu-gcc # ARMv8/AArch6464位ARM官方工具链ARM GNU ToolchainARM公司官方维护稳定性高对最新ARM架构特性支持及时。# ARM官方工具链裸机/嵌入式 arm-none-eabi-gcc # 用于Cortex-M/R系列无操作系统 arm-none-linux-gnueabihf-gcc # 用于Cortex-A系列LinuxBuildroot/Yocto定制工具链通过Buildroot或Yocto项目构建的定制工具链与特定的根文件系统rootfs紧密集成。如何选择我的经验是开发Linux应用选择arm-linux-gnueabihf-gcc32位或aarch64-linux-gnu-gcc64位开发裸机/RTOS固件选择arm-none-eabi-gcc需要最小化系统尺寸考虑使用musl libc的变体如arm-linux-musleabi-gcc3. 实战配置从零搭建交叉编译环境理论讲得再多不如动手实践。下面我将以Ubuntu 20.04为例展示完整的配置流程。3.1 安装交叉编译工具链首先确定你的目标平台。假设我们目标是一台运行Linux的ARMv7-A开发板如树莓派3B支持硬件浮点。方法一使用包管理器安装最简单# 对于Debian/Ubuntu系统 sudo apt update sudo apt install gcc-arm-linux-gnueabihf g-arm-linux-gnueabihf # 验证安装 arm-linux-gnueabihf-gcc --version方法二手动下载安装更灵活有时你需要特定版本的工具链或者包管理器中的版本太旧。访问ARM官方下载页面或Linaro发布页面下载适合的预编译工具链例如wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf.tar.xz tar -xf gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf.tar.xz sudo mv gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf /opt/3.2 配置环境变量与PATH安装后需要让系统知道工具链的位置。我推荐使用局部配置而非全局修改这样可以避免影响系统其他用户也便于管理多个工具链版本。创建专用的环境配置脚本# 创建配置目录 mkdir -p ~/cross_compile/envs cd ~/cross_compile/envs # 创建工具链环境脚本 cat setup_arm_toolchain.sh EOF #!/bin/bash # ARM交叉编译工具链环境配置 export TOOLCHAIN_PATH/opt/gcc-arm-10.3-2021.07-x86_64-arm-none-linux-gnueabihf export ARCHarm export CROSS_COMPILEarm-none-linux-gnueabihf- # 将工具链bin目录加入PATH export PATH${TOOLCHAIN_PATH}/bin:${PATH} # 设置编译器和工具别名可选但方便 export CC${CROSS_COMPILE}gcc export CXX${CROSS_COMPILE}g export AR${CROSS_COMPILE}ar export AS${CROSS_COMPILE}as export LD${CROSS_COMPILE}ld export STRIP${CROSS_COMPILE}strip export RANLIB${CROSS_COMPILE}ranlib # 设置sysroot路径如果使用预编译的根文件系统 export SYSROOT/path/to/your/rootfs export CFLAGS--sysroot${SYSROOT} export CXXFLAGS--sysroot${SYSROOT} export LDFLAGS--sysroot${SYSROOT} echo ARM交叉编译环境已激活 echo 工具链路径: ${TOOLCHAIN_PATH} echo 交叉编译前缀: ${CROSS_COMPILE} EOF # 使脚本可执行 chmod x setup_arm_toolchain.sh使用时只需执行source ~/cross_compile/envs/setup_arm_toolchain.sh为什么需要sysrootsysroot是交叉编译的关键概念。它包含了目标系统的头文件和库文件确保编译器能找到正确的依赖。如果没有正确设置sysroot你可能会遇到“头文件找不到”或“库链接错误”。3.3 验证工具链配置配置完成后必须验证工具链是否正常工作# 1. 检查编译器版本 arm-none-linux-gnueabihf-gcc --version # 2. 检查目标架构 arm-none-linux-gnueabihf-gcc -dumpmachine # 应该输出类似arm-none-linux-gnueabihf # 3. 编译一个简单的测试程序 cat test_hello.c EOF #include stdio.h int main() { printf(Hello from ARM cross-compiled program!\n); return 0; } EOF # 交叉编译 arm-none-linux-gnueabihf-gcc -o test_hello_arm test_hello.c # 检查生成的文件类型 file test_hello_arm # 应该显示ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked...如果file命令显示的是x86_64而不是ARM说明你错误地使用了本地编译器而不是交叉编译器。4. 集成到构建系统Makefile与CMake实战配置好工具链只是第一步接下来需要将其集成到你的构建系统中。4.1 Makefile中的交叉编译配置对于使用Makefile的项目可以通过环境变量或命令行参数指定交叉编译工具# Makefile示例 # 允许通过环境变量覆盖默认值 CROSS_COMPILE ? arm-none-linux-gnueabihf- CC : $(CROSS_COMPILE)gcc CXX : $(CROSS_COMPILE)g AR : $(CROSS_COMPILE)ar LD : $(CROSS_COMPILE)ld # 目标架构特定标志 ARCH : arm CPU : cortex-a53 FPU : neon-vfpv4 FLOAT_ABI : hard # 编译标志 CFLAGS : -O2 -pipe -mcpu$(CPU) -mfpu$(FPU) -mfloat-abi$(FLOAT_ABI) CFLAGS -fdata-sections -ffunction-sections # 便于链接时优化 # 链接标志 LDFLAGS : -Wl,--gc-sections # 移除未使用的代码段 LDFLAGS -Wl,--as-needed # 只链接实际使用的库 # sysroot设置如果使用 SYSROOT ? /opt/rootfs/armv7l ifneq ($(SYSROOT),) CFLAGS --sysroot$(SYSROOT) LDFLAGS --sysroot$(SYSROOT) endif # 目标定义 TARGET : my_embedded_app SRCS : main.c peripherals.c network.c OBJS : $(SRCS:.c.o) # 构建规则 all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(CFLAGS) $(OBJS) -o $ $(LDFLAGS) %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(OBJS) $(TARGET) # 特殊目标在目标板上运行假设通过ssh run: $(TARGET) scp $(TARGET) usertarget-board:/tmp/ ssh usertarget-board /tmp/$(TARGET)使用这个Makefile时你可以这样调用# 使用默认工具链 make # 指定不同的工具链 make CROSS_COMPILEarm-linux-gnueabihf- # 指定sysroot make SYSROOT/path/to/custom/rootfs4.2 CMake中的交叉编译配置CMake是现代C/C项目更常用的构建系统。配置交叉编译需要创建工具链文件toolchain file# arm-linux-gnueabihf.cmake - CMake工具链文件 set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) # 指定交叉编译器 set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g) # 指定sysroot set(CMAKE_SYSROOT /opt/rootfs/armv7l) # 在sysroot中查找库不在主机系统中查找 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_FIND_ROOT_PATH_MODE_PACKAGE ONLY) # 编译器标志 set(CMAKE_C_FLAGS -mcpucortex-a53 -mfpuneon-vfpv4 -mfloat-abihard) set(CMAKE_CXX_FLAGS ${CMAKE_C_FLAGS}) # 测试编译器是否能工作 set(CMAKE_C_COMPILER_WORKS 1) set(CMAKE_CXX_COMPILER_WORKS 1)在CMake配置时指定这个工具链文件mkdir build cd build cmake -DCMAKE_TOOLCHAIN_FILE../arm-linux-gnueabihf.cmake .. make高级技巧在CMakeLists.txt中自动检测交叉编译你可以在CMakeLists.txt中添加逻辑根据工具链自动设置选项# 在CMakeLists.txt中 if(CMAKE_CROSSCOMPILING) message(STATUS 交叉编译模式目标: ${CMAKE_SYSTEM_PROCESSOR}) # 交叉编译特定设置 add_definitions(-DCROSS_COMPILE) # 禁用某些主机特有的测试 set(BUILD_TESTS OFF CACHE BOOL 不构建测试交叉编译时) else() message(STATUS 本地编译模式) set(BUILD_TESTS ON CACHE BOOL 构建测试) endif()5. 常见问题排查与解决方案即使配置正确交叉编译过程中仍会遇到各种问题。下面是我在实际项目中总结的常见问题及解决方法。5.1 头文件或库找不到这是最常见的问题症状通常是编译错误fatal error: stdio.h: No such file or directory或者链接错误/usr/lib/gcc/arm-linux-gnueabihf/9/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lm解决方案检查sysroot配置确保--sysroot参数正确指向包含目标系统头文件和库的目录。验证库搜索路径# 查看编译器搜索的目录 echo | arm-linux-gnueabihf-gcc -E -Wp,-v - 21 | grep ^ /手动指定包含路径和库路径# 编译时指定 arm-linux-gnueabihf-gcc -I/path/to/target/include -L/path/to/target/lib -lm使用pkg-config如果可用# 设置pkg-config使用目标系统的.pc文件 export PKG_CONFIG_SYSROOT_DIR/path/to/sysroot export PKG_CONFIG_PATH/path/to/sysroot/usr/lib/pkgconfig export PKG_CONFIG_LIBDIR/path/to/sysroot/usr/lib/pkgconfig5.2 链接器错误undefined reference这种错误通常意味着链接器找到了库文件但库的版本或ABI不匹配。典型错误信息undefined reference to sqrt collect2: error: ld returned 1 exit status排查步骤检查是否链接了正确的数学库添加-lm参数。检查库文件架构# 查看库文件信息 file /path/to/sysroot/usr/lib/libm.so.6 # 应该显示ARM架构而不是x86_64检查符号是否存在# 在库中查找特定符号 arm-linux-gnueabihf-nm -D /path/to/sysroot/usr/lib/libm.so.6 | grep sqrtABI不匹配的典型表现软浮点工具链链接了硬浮点库32位工具链链接了64位库glibc版本不匹配5.3 运行时错误Illegal instruction或Segmentation fault程序编译成功但在目标板上运行时崩溃。这通常是因为编译时使用的CPU特性目标板不支持。解决方案降低优化级别和CPU特性# 使用更保守的CPU标志 arm-linux-gnueabihf-gcc -mcpucortex-a7 -mfpuvfpv4 -mfloat-abihard ... # 而不是 # arm-linux-gnueabihf-gcc -marcharmv8-acrccrypto ...检查目标板实际支持的指令集# 在目标板上运行 cat /proc/cpuinfo # 查看Features字段使用-mtune而非-march-mtune优化代码但不要求特定指令集。5.4 静态链接与动态链接的选择嵌入式系统中静态链接和动态链接各有优劣特性静态链接动态链接文件大小较大库代码包含在可执行文件中较小共享库内存占用每个进程独立加载库代码库代码在进程间共享部署复杂度简单单个文件复杂需要部署所有依赖库更新维护需要重新编译整个程序只需更新库文件启动速度较快无动态链接开销稍慢需要动态链接我的建议对于小型工具或初始化程序使用静态链接减少依赖。对于大型应用或多个应用共享库使用动态链接节省存储空间。使用混合策略关键路径静态链接非关键部分动态链接。静态链接示例arm-linux-gnueabihf-gcc -static main.c -o main_static检查动态依赖# 查看程序的动态库依赖 arm-linux-gnueabihf-readelf -d my_program | grep NEEDED5.5 调试信息与符号剥离在嵌入式设备上存储空间通常很宝贵。调试版本和发布版本需要不同的处理。保留调试信息开发阶段arm-linux-gnueabihf-gcc -g -O0 main.c -o main_debug # 文件较大包含调试符号 ls -lh main_debug剥离调试符号发布版本# 编译时优化 arm-linux-gnueabihf-gcc -O2 -s main.c -o main_release # 或者编译后剥离 arm-linux-gnueabihf-gcc -O2 -g main.c -o main arm-linux-gnueabihf-strip --strip-all main分离调试信息最佳实践# 编译带调试信息 arm-linux-gnueabihf-gcc -g -O2 main.c -o main # 提取调试信息到单独文件 arm-linux-gnueabihf-objcopy --only-keep-debug main main.debug # 从主程序中剥离调试信息 arm-linux-gnueabihf-strip --strip-all main # 需要调试时可以重新关联 arm-linux-gnueabihf-objcopy --add-gnu-debuglinkmain.debug main这样设备上部署的是剥离后的精简版本开发机上保留调试文件用于问题分析。6. 高级技巧与最佳实践经过多年的嵌入式开发我总结了一些能显著提升效率的技巧。6.1 使用distcc分布式编译当项目庞大时编译时间可能成为瓶颈。distcc可以将编译任务分发到多台机器# 在编译服务器上安装distcc sudo apt install distcc # 在每台机器上启动distcc守护进程 distccd --daemon --allow 192.168.1.0/24 # 在客户端设置DISTCC_HOSTS环境变量 export DISTCC_HOSTSlocalhost 192.168.1.100 192.168.1.101 # 使用distcc包装编译器 export CCdistcc arm-linux-gnueabihf-gcc make -j$(distcc -j)6.2 创建编译缓存ccacheccache可以缓存编译结果当重复编译相同代码时直接使用缓存# 安装ccache sudo apt install ccache # 包装交叉编译器 sudo ln -s /usr/bin/ccache /usr/local/bin/arm-linux-gnueabihf-gcc sudo ln -s /usr/bin/ccache /usr/local/bin/arm-linux-gnueabihf-g # 或者通过环境变量 export CCACHE_PREFIXarm-linux-gnueabihf- export CCccache gcc6.3 自动化测试与持续集成在交叉编译环境中建立自动化测试流程#!/bin/bash # 自动化构建测试脚本示例 set -e # 遇到错误立即退出 TOOLCHAINarm-linux-gnueabihf BUILD_DIRbuild_${TOOLCHAIN} LOG_FILEbuild_$(date %Y%m%d_%H%M%S).log echo 开始交叉编译测试 - $(date) | tee -a $LOG_FILE # 清理旧构建 rm -rf $BUILD_DIR mkdir -p $BUILD_DIR cd $BUILD_DIR # 配置 echo 配置CMake... | tee -a ../$LOG_FILE cmake -DCMAKE_TOOLCHAIN_FILE../toolchain.cmake .. 21 | tee -a ../$LOG_FILE # 编译 echo 开始编译... | tee -a ../$LOG_FILE make -j$(nproc) 21 | tee -a ../$LOG_FILE # 检查输出文件 if [ -f myapp ]; then echo 编译成功检查文件类型... | tee -a ../$LOG_FILE file myapp | tee -a ../$LOG_FILE # 检查动态库依赖 echo 动态库依赖 | tee -a ../$LOG_FILE ${TOOLCHAIN}-readelf -d myapp | grep NEEDED | tee -a ../$LOG_FILE # 文件大小 echo 文件大小$(stat -c%s myapp) 字节 | tee -a ../$LOG_FILE else echo 错误编译失败 | tee -a ../$LOG_FILE exit 1 fi echo 测试完成 - $(date) | tee -a ../$LOG_FILE6.4 容器化交叉编译环境使用Docker可以创建可重复、隔离的编译环境# Dockerfile.cross-compile FROM ubuntu:20.04 # 安装必要的工具 RUN apt-get update apt-get install -y \ build-essential \ gcc-arm-linux-gnueabihf \ g-arm-linux-gnueabihf \ file \ cmake \ git \ rm -rf /var/lib/apt/lists/* # 设置工作目录 WORKDIR /workspace # 设置默认命令 CMD [/bin/bash]构建和使用# 构建镜像 docker build -t arm-cross-compile -f Dockerfile.cross-compile . # 运行容器 docker run -it --rm -v $(pwd):/workspace arm-cross-compile # 在容器内编译 cd /workspace arm-linux-gnueabihf-gcc -o hello hello.c7. 实际项目中的工具链管理在团队协作或长期项目中工具链管理尤为重要。我推荐以下做法7.1 版本控制工具链配置将工具链配置纳入版本控制project/ ├── toolchains/ │ ├── arm-gcc-10.3/ │ │ ├── README.md │ │ └── setup_env.sh │ └── aarch64-gcc-11.2/ │ ├── README.md │ └── setup_env.sh ├── scripts/ │ ├── setup_cross_compile.sh │ └── build_all.sh ├── cmake/ │ └── toolchain-arm-linux-gnueabihf.cmake └── README.md7.2 自动化环境检测脚本创建智能的环境检测脚本#!/bin/bash # scripts/detect_toolchain.sh # 检测可用的工具链 detect_arm_toolchain() { local candidates( arm-linux-gnueabihf arm-none-linux-gnueabihf arm-poky-linux-gnueabi aarch64-linux-gnu ) for prefix in ${candidates[]}; do if command -v ${prefix}-gcc /dev/null 21; then echo 找到工具链: ${prefix} export CROSS_COMPILE${prefix}- export CC${CROSS_COMPILE}gcc export CXX${CROSS_COMPILE}g return 0 fi done echo 错误未找到ARM交叉编译工具链 echo 请安装以下之一 printf %s\n ${candidates[]} return 1 } # 检测并设置 if detect_arm_toolchain; then echo 使用工具链: ${CROSS_COMPILE} echo CC${CC} echo CXX${CXX} else exit 1 fi7.3 多架构支持的项目配置对于需要支持多种架构的项目# 支持多种架构的Makefile ARCH ? $(shell uname -m) # 根据架构选择工具链 ifeq ($(ARCH), x86_64) # 本地编译 CC : gcc CFLAGS : -O2 -marchnative else ifeq ($(ARCH), armv7l) # ARMv7硬浮点 CROSS_COMPILE : arm-linux-gnueabihf- CC : $(CROSS_COMPILE)gcc CFLAGS : -O2 -mcpucortex-a7 -mfpuneon-vfpv4 -mfloat-abihard else ifeq ($(ARCH), aarch64) # ARM64 CROSS_COMPILE : aarch64-linux-gnu- CC : $(CROSS_COMPILE)gcc CFLAGS : -O2 -mcpucortex-a53 else $(error 不支持的架构: $(ARCH)) endif # 通用编译标志 CFLAGS -Wall -Wextra -Werror LDFLAGS : -Wl,--gc-sections # 构建目标 TARGET : myapp-$(ARCH) all: $(TARGET) $(TARGET): main.o utils.o $(CC) $(CFLAGS) $^ -o $ $(LDFLAGS) clean: rm -f *.o myapp-*在实际项目中我遇到过最棘手的问题往往不是工具链配置本身而是环境不一致导致的隐性问题。比如某个开发者的本地安装了额外的库而CI服务器上没有导致编译通过但运行时崩溃。解决这类问题的关键是环境隔离和可重复性——这也是为什么我强烈推荐使用Docker或类似的容器技术。另一个常见陷阱是忘记清理旧的构建产物。交叉编译和本地编译可能产生相同名称但不同架构的文件如果不小心混用会导致难以调试的运行时错误。我现在的习惯是每次切换架构时都执行完整的清理# 我的标准工作流程 make clean # 清理旧构建 source setup_arm_env.sh # 设置ARM环境 make # 重新构建 file myapp # 验证架构最后记住交叉编译不是银弹。有些库和工具特别是那些严重依赖主机特性的就是难以交叉编译。遇到这种情况时考虑以下替代方案在目标设备上直接编译如果资源允许使用模拟器如QEMU创建完整的构建环境寻找或创建替代的、更易于交叉编译的库工具链配置可能一开始令人望而生畏但一旦掌握它会成为嵌入式开发中最高效的利器之一。每次我成功地将一个复杂的应用交叉编译到资源受限的设备上运行时那种成就感总是让我觉得这些努力是值得的。