区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载导读本文围绕 Monero 仓库中contrib/depends目录自带的依赖构建系统展开它负责为 Monero 下载、编译、缓存并交付全部第三方依赖Boost、OpenSSL、ZeroMQ、Unbound、Sodium、Readline、Protobuf、HIDAPI 等并自动生成可供 CMake 直接引用的交叉编译工具链文件。读完本文你将掌握如何用make一行命令为当前或指定平台构建依赖、如何将生成的toolchain.cmake接入 Monero 主构建流程、如何配置源码缓存与下载目录、如何仅下载不编译以及这套系统哈希驱动、不依赖时间戳、自清理的设计原理与扩展新包的完整方法。一、快速上手为当前平台构建依赖contrib/depends是一套独立的 Make 驱动系统与 Monero 主构建CMake解耦。进入目录直接执行cd contrib/depends make默认情况下HOST取值为./config.guess探测出的当前构建机三元组见 contrib/depends/Makefile 中BUILD $(shell ./config.guess)、HOST ? $(BUILD)两行因此它会为目标机即当前 archOS构建整套依赖。执行结束后会在contrib/depends下生成一个以 host 三元组命名的目录如x86_64-linux-gnu内部包含share/toolchain.cmake可直接喂给 Monero CMake 的交叉工具链文件以native/为前缀的构建机侧工具如为 host 侧准备的protoc等 native 包。二、交叉编译为其他架构/系统构建依赖为其他平台构建时只需通过make HOSThost-platform-triplet指定目标平台三元组即可路径与工具链全部自动配置无需其他选项make HOSTx86_64-w64-mingw32 -j4其中-j4用于并行加速。上例执行后会创建一个名为x86_64-w64-mingw32的目录其中即为面向 Win64 的整套交叉依赖与工具链。常用交叉编译目标三元组三元组目标平台i686-w64-mingw32Windows 32 位Win32x86_64-w64-mingw32Windows 64 位Win64x86_64-apple-darwinmacOS x86_64arm-linux-gnueabihfLinux ARM 32 位aarch64-linux-gnuLinux ARM 64 位riscv64-linux-gnuLinux RISC-V 64 位除三元组外无需额外配置头文件、库搜索路径、PKG_CONFIG_PATH等均由系统自动推导下文第三节的toolchain.cmake会把这些路径固化下来。三、接入 Monero 主构建使用生成的 toolchain.cmake依赖构建完成后从 Monero 源码树根目录执行以下命令将生成的工具链文件交给 CMakemkdir build cd build cmake -DCMAKE_TOOLCHAIN_FILE$PWD/../contrib/depends/x86_64-w64-mingw32/share/toolchain.cmake ..toolchain.cmake由模板 contrib/depends/toolchain.cmake.in 经 sed 变量替换生成其核心职责包括设置CMAKE_SYSTEM_NAME如Windows/Linux/Darwin/FreeBSD/Android与CMAKE_SYSTEM_PROCESSOR使 CMake 进入交叉编译模式通过CMAKE_C_COMPILER_TARGET/CMAKE_CXX_COMPILER_TARGET指定目标三元组并按TARGET_OS分支选择编译器Darwin 用 SDK 中的 clang、Android 用 NDK 工具链、其余平台直接用生成目录下的交叉 gcc/g把CMAKE_FIND_ROOT_PATH指向依赖安装前缀并设置CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY、MODE_INCLUDE ONLY保证只使用 depends 提供、而非系统自带的库与头文件程序查找仍走 host通过OPENSSL_ROOT_DIR、BOOST_ROOT、Readline_ROOT_DIR、LIBUSB-1.0_LIBRARY、Protobuf_PROTOC_EXECUTABLE指向prefix/native/bin/protoc等变量把各依赖的安装位置直接告诉 CMake末尾设置全局标志set(DEPENDS true)供 Monero 自身的 CMake 判断当前是否处于 depends 构建模式并据此调整STATIC ON、UNBOUND_STATIC ON、BUILD_TESTS、TREZOR_DEBUG等选项。因此依赖与主程序是一次工具链、两段构建的关系depends 只产出依赖库与工具链Monero 本体仍走标准 CMake 流程。四、可调选项源码、缓存、下载与构建类型运行make时可通过make FOObar形式覆盖以下选项定义于 contrib/depends/Makefile 顶部选项作用默认值SOURCES_PATH已下载的源码压缩包存放位置$(BASEDIR)/sourcesBASE_CACHE已构建完成的包缓存tar.gz 形式存放位置$(BASEDIR)/builtFALLBACK_DOWNLOAD_PATH上游源文件抓取失败时的备用下载地址https://downloads.getmonero.org/depends-sourcesDEBUG关闭部分优化、开启更多运行时检查debug 构建空即 releaseHOST_ID_SALT生成 host 侧包 id 时使用的盐值saltBUILD_ID_SALT生成 build 侧包 id 时使用的盐值salt其中DEBUG一旦设置如make DEBUG1所有包将按 debug 配置编译例如 contrib/depends/hosts/linux.mk 中linux_debug_CFLAGS-O1且附带-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC的调试检查宏而 release 则使用-O2。另外两个与构建范围相关的开关也值得注意NO_WALLET可剔除钱包相关包protobuf、libusb、hidapi 等NO_READLINE可剔除 readline 相关包ncurses、readline分别通过 contrib/depends/packages/packages.mk 中的wallet_packages_$(NO_WALLET)、readline_packages_$(NO_READLINE)机制生效。五、仅下载不构建download 系列目标如果只想把依赖源码全部抓下来例如预置到离线构建机而不实际编译可执行make download该目标会依次调用按平台细分的目标见 contrib/depends/Makefile 中download一节目标覆盖平台download-osxx86_64-apple-darwindownload-linuxx86_64-unknown-linux-gnudownload-winx86_64-w64-mingw32download-freebsdx86_64-unknown-freebsddownload-androidaarch64-linux-android每个目标内部等价于make -s HOST对应三元组 download-one而download-one又依赖check-sources与$(all_sources)会先校验源码哈希再抓取缺失部分。下载后的文件按SOURCES_PATH存放并带.hash校验记录后续构建时可直接复用。六、WindowsMinGW交叉构建的注意事项为 32/64 位 MinGW 构建时需要将系统里的 mingw 工具切换为 posix 线程模型否则会出现线程库不匹配的问题update-alternatives --set x86_64-w64-mingw32-g x86_64-w64-mingw32-g-posix update-alternatives --set x86_64-w64-mingw32-gcc x86_64-w64-mingw32-gcc-posix这是因为 Monero 依赖的 Boost 等库在 mingw32 目标下使用threadapiwin32编译见 contrib/depends/packages/boost.mk而整套工具链需要保持一致的线程模型。相关的主机级默认工具由 contrib/depends/hosts/default.mk 定义如default_host_CC $(host_toolchain)gcc交叉编译器统一按$(HOST)-前缀查找。七、设计原理为什么这套系统可靠且可复现contrib/depends/description.md 系统阐述了该设计区别于普通依赖脚本的核心理念理解这些特性有助于排查构建问题1. 构建机与目标机解耦builder/host agnostic理论上任意 OS/架构的构建机都可以产出任意目标平台的二进制。实践中构建侧工具native 包按需指定包配方也要随新 host 演进当前默认假定构建架构为 x86_64Linux 或 macOS。2. 不依赖时间戳只看文件存在性系统用文件是否存在 哈希是否匹配来判断某个包是否需要重建而不是比较文件 mtime。这让构建结果可以被分发、被自动化构建机消化也不受 checkout 时间影响。3. 每次构建只有显式声明的依赖可见每个包构建前其 sysroot 会被清空然后只解压安装它递归声明的依赖见 contrib/depends/funcs.mk 中configured阶段的$(foreach package,$($(1)_all_dependencies), tar ... )。这保证了构建的确定性——不会有未知文件混入造成副作用。4. 每包独立缓存按需重建构建前为每个包生成唯一 build-id它由该包构建配方涉及的所有文件Makefile、包配方、补丁等的哈希加上其每个递归依赖的同类哈希再叠加上工具链版本信息$(build_CC) --version等共同计算而来见 contrib/depends/Makefile 的build_id_string与 contrib/depends/funcs.mk 的int_get_build_recipe_hash/int_get_build_id。因此修改任一包配方 → 该包及其所有依赖它的包全部重建修改主 Makefile、funcs.mk、builders/*.mk、hosts/*.mk→ 所有包重建构建结果打包为 tar.gz 存入BASE_CACHE可复用、可分发cached阶段见 contrib/depends/funcs.mk。5. 构建结果相对确定每个包都被配置与打补丁使其在合理约束下每次产出相同结果。时间戳插入等不可避免的差异超出本系统范围工具链本身也必须具备确定性当版本正确推进时一个缓存包应精确对应单一产物。6. 源码自动抓取与校验每个包必须声明源码位置与 sha256 校验和抓取后若与哈希不符构建直接失败fetch_file在 contrib/depends/funcs.mk 中先写.hash再用$(build_SHA256SUM) -c校验。源码可预置或缓存FALLBACK_DOWNLOAD_PATH提供了官方镜像兜底。7. 自清理构建目录与 staging 目录用完即清缓存中旧版本在成功构建后会被移除staged阶段末尾rm -rf $($(1)_extract_dir)、cached阶段rm -rf $$(D) mkdir -p $$(D)自动化构建机可持续增量构建而无需人工干预。八、包配方recipes结构理解依赖如何被构建每个依赖对应 contrib/depends/packages/ 下的一个.mk文件当前含 boost、openssl、zeromq、unbound、sodium、ncurses、readline、protobuf、native_protobuf、libusb、hidapi、darwin_sdk、freebsd_base、android_ndk 等。一个配方由三部分组成详见 contrib/depends/packages.md1. 标识符必填$(package)_version # 上游版本无版本概念时可用 1.0 占位 $(package)_download_path # 上游源码位置不含文件名 $(package)_file_name # 下载路径下的源文件名 $(package)_sha256_hash # 源文件的 sha256 校验和可选标识符包括$(package)_build_subdir # 执行 configure/build/stage 前 cd 到的子目录 $(package)_download_file # 上游文件名与本地存储名不同时的本地名 $(package)_dependencies # 依赖的其他包名 $(package)_patches # 构建所需补丁文件名存放于 patches/包名/ $(package)_extra_sources # 通过 fetch_cmds 额外抓取的文件2. 构建变量$(package)_set_vars在define $(package)_set_vars ... endef函数中追加或覆盖编译相关变量可用的核心变量包括_cc、_cxx、_objc、_objcxx、_ar、_ranlib、_libtool、_nm、_cflags、_cxxflags、_ldflags、_cppflags、_config_env、_build_env、_stage_env、_build_opts、_config_opts。所有变量都支持按 host、架构或两者同时加前缀做条件覆盖通用: $(package)_ccgcc 仅 Linux: $(package)_linux_ccgcc 仅 x86_64: $(package)_x86_64_ccgcc 仅 x86_64 Linux: $(package)_x86_64_linux_ccgcc同时支持 debug/release 后缀仅在对应构建类型下生效$(package)_cflags_release -O3 $(package)_cflags_i686_debug -g $(package)_config_opts_release --disable-debug默认所有构建视为 release除非用户设置DEBUG1。*_env系列变量用于给相应命令追加环境变量funcs.mk还会自动注入PKG_CONFIG_LIBDIR、PKG_CONFIG_PATH、CMAKE_MODULE_PATH以及指向 native 工具目录的PATH。以 contrib/depends/packages/boost.mk 为实例它声明了boost_version1.91.0-1、下载路径、sha256_hash与补丁no-embed-absolute.patch在set_vars中按平台设置target-osandroid/darwin/windows、threadapipthread/win32、address-model32/64并在preprocess_cmds中生成user-config.jam注入交叉编译器与 flags——这是理解真实配方的最佳范本。3. 构建命令六个阶段每个包有独立且唯一的 build 目录与 staging 目录形如work/build/mylib/1.0-1adac830f6e、work/staging/mylib/1.0-1adac830f6eid 即 build-id 前 11 位见 contrib/depends/Makefile 的HASH_LENGTH:11六个阶段命令依次为命令运行目录默认行为$(package)_fetch_cmdsbuild 目录抓取源文件未定义时自动抓取并校验哈希$(package)_extract_cmdsbuild 目录校验哈希并解压未定义时假定源为 tar 包$(package)_preprocess_cmdsbuild 目录/_build_subdir源码预处理如打补丁默认无操作$(package)_config_cmdsbuild 目录/_build_subdir配置源码默认无操作$(package)_build_cmdsbuild 目录/_build_subdir编译默认无操作$(package)_stage_cmdsbuild 目录/_build_subdir安装到 staging默认无操作配方内可直接使用以下路径变量$(1)_staging_dir # 包的 sysroot 目标路径 $(1)_staging_prefix_dir # staging 内的 prefix 路径 $(1)_extract_dir # 解压后的源码路径 $(1)_build_dir # configure/build/stage 实际执行路径 $(1)_patch_dir # 包补丁所在路径对于 autotools 项目funcs.mk提供的$($(package)_autoconf)宏会拼出形如./configure --build$(BUILD) --host... --prefix... --with-pic ... CC... CXX...的完整配置命令并自动附加--disable-dependency-tracking、NM/RANLIB/AR/CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS大多数 autotools 项目可用如下命令完成 staging$(MAKE) DESTDIR$($(package)_staging_dir) installCMake 系项目则可借助$($(package)_cmake)宏它会注入CC/CXX/CFLAGS/LDFLAGS环境变量、CMAKE_INSTALL_PREFIX并在交叉编译时自动追加CMAKE_SYSTEM_NAME与CMAKE_C/CXX_COMPILER_TARGET。九、构建流水线从源码到缓存包的完整链路结合 contrib/depends/funcs.mk 的int_add_cmds与stages定义一个包的完整生命周期为fetched → extracted → preprocessed → configured → built → staged → postprocessed → cached → cached_checksumfetched下载源码并用build_SHA256SUM记录校验extracted校验哈希并解压到extract_dirpreprocessed复制补丁到patch_dir并执行预处理configured先清空host_prefix把全部递归依赖的缓存 tar 解压进去再执行配置命令built执行编译staged执行安装并删除extract_dirpostprocessed执行收尾如 boost 在 release 下裁剪不需要的头文件目录cached把 staging 内容打成 tar.gz 放入BASE_CACHE随后删除 staging 目录cached_checksum为缓存包生成 sha256 校验文件。Makefile 还会生成check-packages/check-sources目标用于缓存与源码的完整性校验校验失败即强制重下/重建并支持make print-变量名如make print-all_packages调试任意变量。顶层install目标在全部包完成后基于toolchain.cmake.in经 sed 替换生成$(host_prefix)/share/toolchain.cmake从而完成依赖 → 工具链的闭环。十、扩展新依赖最小改动三步走若需为 Monero depends 体系新增第三方库参照 contrib/depends/packages.md 的流程在 contrib/depends/packages/ 新建mylib.mk声明必填标识符version / download_path / file_name / sha256_hash与可选字段dependencies、patches、build_subdir 等并在set_vars中按平台/架构/debug-release 设定编译变量如需补丁放入 contrib/depends/patches/ 下以包名命名的子目录并在配方中通过$(package)_patches引用在 contrib/depends/packages/packages.mk 的packages/native_packages列表或按wallet_packages、readline_packages等分组中加入该包名。加入后运行make系统会自动完成哈希校验、依赖排序、build-id 计算与缓存分发无需手工处理各平台的下载与配置细节源码、缓存与补丁的完整链路均可通过make print-包名_xxx验证。十一、常见问题与排查技巧只想为当前平台构建不想指定 HOST直接makeHOST由config.guess自动探测下载超时或上游不可达设置FALLBACK_DOWNLOAD_PATH指向可达镜像默认官方downloads.getmonero.org/depends-sources下载连接超时与重试次数在 Makefile 中分别为DOWNLOAD_CONNECT_TIMEOUT:30秒与DOWNLOAD_RETRIES:5改了包配方却未触发重建检查 build-id 机制——只要配方文件或递归依赖哈希变化系统必然重建若仍异常可手动清除BASE_CACHE下对应包目录或运行make check-packages触发校验与强制重下MinGW 链接报线程模型错误确认已按第六节执行update-alternatives切换到 posix 模式调试单包depends 为每包暴露了分阶段目标如make boost_staged、make boost_cached可在不重跑全量的情况下单独构建与排查某个依赖。延伸阅读contrib/depends/description.mddepends 系统总体设计说明确定性、缓存、校验机制contrib/depends/packages.md新增依赖包的完整编写规范contrib/depends/Makefile选项定义、build-id 计算、toolchain.cmake 生成与 download 目标contrib/depends/funcs.mk构建阶段、路径变量、autoconf/cmake 辅助宏的底层实现contrib/depends/toolchain.cmake.in生成交叉工具链文件的 CMake 模板赞分享区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载相关推荐Dogecoin 跨平台依赖构建系统depends实战指南从零编译多平台依赖与交叉编译配置Dogecoin 跨平台依赖构建系统depends实战指南从零编译多平台依赖与交叉编译配置 本文以 Dogecoin 仓库中的 depends 系统说明区块链Zcash 可复现依赖构建系统 depends跨平台交叉编译与确定性缓存的工程实践Zcash 可复现依赖构建系统 depends跨平台交叉编译与确定性缓存的工程实践 导读 Zcash 的 depends 是一套独立于主工程之外的依赖构建与缓区块链金融科技密码学后端Zcash depends 依赖构建系统详解交叉编译、缓存机制与包配方实战Zcash depends 依赖构建系统详解交叉编译、缓存机制与包配方实战 本篇技术指南聚焦 Zcash 仓库中 depends/ 目录所实现的依赖构建系统区块链金融科技密码学后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Monero 依赖构建系统（contrib/depends）完全指南：跨平台交叉编译与依赖缓存
区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载导读本文围绕 Monero 仓库中contrib/depends目录自带的依赖构建系统展开它负责为 Monero 下载、编译、缓存并交付全部第三方依赖Boost、OpenSSL、ZeroMQ、Unbound、Sodium、Readline、Protobuf、HIDAPI 等并自动生成可供 CMake 直接引用的交叉编译工具链文件。读完本文你将掌握如何用make一行命令为当前或指定平台构建依赖、如何将生成的toolchain.cmake接入 Monero 主构建流程、如何配置源码缓存与下载目录、如何仅下载不编译以及这套系统哈希驱动、不依赖时间戳、自清理的设计原理与扩展新包的完整方法。一、快速上手为当前平台构建依赖contrib/depends是一套独立的 Make 驱动系统与 Monero 主构建CMake解耦。进入目录直接执行cd contrib/depends make默认情况下HOST取值为./config.guess探测出的当前构建机三元组见 contrib/depends/Makefile 中BUILD $(shell ./config.guess)、HOST ? $(BUILD)两行因此它会为目标机即当前 archOS构建整套依赖。执行结束后会在contrib/depends下生成一个以 host 三元组命名的目录如x86_64-linux-gnu内部包含share/toolchain.cmake可直接喂给 Monero CMake 的交叉工具链文件以native/为前缀的构建机侧工具如为 host 侧准备的protoc等 native 包。二、交叉编译为其他架构/系统构建依赖为其他平台构建时只需通过make HOSThost-platform-triplet指定目标平台三元组即可路径与工具链全部自动配置无需其他选项make HOSTx86_64-w64-mingw32 -j4其中-j4用于并行加速。上例执行后会创建一个名为x86_64-w64-mingw32的目录其中即为面向 Win64 的整套交叉依赖与工具链。常用交叉编译目标三元组三元组目标平台i686-w64-mingw32Windows 32 位Win32x86_64-w64-mingw32Windows 64 位Win64x86_64-apple-darwinmacOS x86_64arm-linux-gnueabihfLinux ARM 32 位aarch64-linux-gnuLinux ARM 64 位riscv64-linux-gnuLinux RISC-V 64 位除三元组外无需额外配置头文件、库搜索路径、PKG_CONFIG_PATH等均由系统自动推导下文第三节的toolchain.cmake会把这些路径固化下来。三、接入 Monero 主构建使用生成的 toolchain.cmake依赖构建完成后从 Monero 源码树根目录执行以下命令将生成的工具链文件交给 CMakemkdir build cd build cmake -DCMAKE_TOOLCHAIN_FILE$PWD/../contrib/depends/x86_64-w64-mingw32/share/toolchain.cmake ..toolchain.cmake由模板 contrib/depends/toolchain.cmake.in 经 sed 变量替换生成其核心职责包括设置CMAKE_SYSTEM_NAME如Windows/Linux/Darwin/FreeBSD/Android与CMAKE_SYSTEM_PROCESSOR使 CMake 进入交叉编译模式通过CMAKE_C_COMPILER_TARGET/CMAKE_CXX_COMPILER_TARGET指定目标三元组并按TARGET_OS分支选择编译器Darwin 用 SDK 中的 clang、Android 用 NDK 工具链、其余平台直接用生成目录下的交叉 gcc/g把CMAKE_FIND_ROOT_PATH指向依赖安装前缀并设置CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY、MODE_INCLUDE ONLY保证只使用 depends 提供、而非系统自带的库与头文件程序查找仍走 host通过OPENSSL_ROOT_DIR、BOOST_ROOT、Readline_ROOT_DIR、LIBUSB-1.0_LIBRARY、Protobuf_PROTOC_EXECUTABLE指向prefix/native/bin/protoc等变量把各依赖的安装位置直接告诉 CMake末尾设置全局标志set(DEPENDS true)供 Monero 自身的 CMake 判断当前是否处于 depends 构建模式并据此调整STATIC ON、UNBOUND_STATIC ON、BUILD_TESTS、TREZOR_DEBUG等选项。因此依赖与主程序是一次工具链、两段构建的关系depends 只产出依赖库与工具链Monero 本体仍走标准 CMake 流程。四、可调选项源码、缓存、下载与构建类型运行make时可通过make FOObar形式覆盖以下选项定义于 contrib/depends/Makefile 顶部选项作用默认值SOURCES_PATH已下载的源码压缩包存放位置$(BASEDIR)/sourcesBASE_CACHE已构建完成的包缓存tar.gz 形式存放位置$(BASEDIR)/builtFALLBACK_DOWNLOAD_PATH上游源文件抓取失败时的备用下载地址https://downloads.getmonero.org/depends-sourcesDEBUG关闭部分优化、开启更多运行时检查debug 构建空即 releaseHOST_ID_SALT生成 host 侧包 id 时使用的盐值saltBUILD_ID_SALT生成 build 侧包 id 时使用的盐值salt其中DEBUG一旦设置如make DEBUG1所有包将按 debug 配置编译例如 contrib/depends/hosts/linux.mk 中linux_debug_CFLAGS-O1且附带-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC的调试检查宏而 release 则使用-O2。另外两个与构建范围相关的开关也值得注意NO_WALLET可剔除钱包相关包protobuf、libusb、hidapi 等NO_READLINE可剔除 readline 相关包ncurses、readline分别通过 contrib/depends/packages/packages.mk 中的wallet_packages_$(NO_WALLET)、readline_packages_$(NO_READLINE)机制生效。五、仅下载不构建download 系列目标如果只想把依赖源码全部抓下来例如预置到离线构建机而不实际编译可执行make download该目标会依次调用按平台细分的目标见 contrib/depends/Makefile 中download一节目标覆盖平台download-osxx86_64-apple-darwindownload-linuxx86_64-unknown-linux-gnudownload-winx86_64-w64-mingw32download-freebsdx86_64-unknown-freebsddownload-androidaarch64-linux-android每个目标内部等价于make -s HOST对应三元组 download-one而download-one又依赖check-sources与$(all_sources)会先校验源码哈希再抓取缺失部分。下载后的文件按SOURCES_PATH存放并带.hash校验记录后续构建时可直接复用。六、WindowsMinGW交叉构建的注意事项为 32/64 位 MinGW 构建时需要将系统里的 mingw 工具切换为 posix 线程模型否则会出现线程库不匹配的问题update-alternatives --set x86_64-w64-mingw32-g x86_64-w64-mingw32-g-posix update-alternatives --set x86_64-w64-mingw32-gcc x86_64-w64-mingw32-gcc-posix这是因为 Monero 依赖的 Boost 等库在 mingw32 目标下使用threadapiwin32编译见 contrib/depends/packages/boost.mk而整套工具链需要保持一致的线程模型。相关的主机级默认工具由 contrib/depends/hosts/default.mk 定义如default_host_CC $(host_toolchain)gcc交叉编译器统一按$(HOST)-前缀查找。七、设计原理为什么这套系统可靠且可复现contrib/depends/description.md 系统阐述了该设计区别于普通依赖脚本的核心理念理解这些特性有助于排查构建问题1. 构建机与目标机解耦builder/host agnostic理论上任意 OS/架构的构建机都可以产出任意目标平台的二进制。实践中构建侧工具native 包按需指定包配方也要随新 host 演进当前默认假定构建架构为 x86_64Linux 或 macOS。2. 不依赖时间戳只看文件存在性系统用文件是否存在 哈希是否匹配来判断某个包是否需要重建而不是比较文件 mtime。这让构建结果可以被分发、被自动化构建机消化也不受 checkout 时间影响。3. 每次构建只有显式声明的依赖可见每个包构建前其 sysroot 会被清空然后只解压安装它递归声明的依赖见 contrib/depends/funcs.mk 中configured阶段的$(foreach package,$($(1)_all_dependencies), tar ... )。这保证了构建的确定性——不会有未知文件混入造成副作用。4. 每包独立缓存按需重建构建前为每个包生成唯一 build-id它由该包构建配方涉及的所有文件Makefile、包配方、补丁等的哈希加上其每个递归依赖的同类哈希再叠加上工具链版本信息$(build_CC) --version等共同计算而来见 contrib/depends/Makefile 的build_id_string与 contrib/depends/funcs.mk 的int_get_build_recipe_hash/int_get_build_id。因此修改任一包配方 → 该包及其所有依赖它的包全部重建修改主 Makefile、funcs.mk、builders/*.mk、hosts/*.mk→ 所有包重建构建结果打包为 tar.gz 存入BASE_CACHE可复用、可分发cached阶段见 contrib/depends/funcs.mk。5. 构建结果相对确定每个包都被配置与打补丁使其在合理约束下每次产出相同结果。时间戳插入等不可避免的差异超出本系统范围工具链本身也必须具备确定性当版本正确推进时一个缓存包应精确对应单一产物。6. 源码自动抓取与校验每个包必须声明源码位置与 sha256 校验和抓取后若与哈希不符构建直接失败fetch_file在 contrib/depends/funcs.mk 中先写.hash再用$(build_SHA256SUM) -c校验。源码可预置或缓存FALLBACK_DOWNLOAD_PATH提供了官方镜像兜底。7. 自清理构建目录与 staging 目录用完即清缓存中旧版本在成功构建后会被移除staged阶段末尾rm -rf $($(1)_extract_dir)、cached阶段rm -rf $$(D) mkdir -p $$(D)自动化构建机可持续增量构建而无需人工干预。八、包配方recipes结构理解依赖如何被构建每个依赖对应 contrib/depends/packages/ 下的一个.mk文件当前含 boost、openssl、zeromq、unbound、sodium、ncurses、readline、protobuf、native_protobuf、libusb、hidapi、darwin_sdk、freebsd_base、android_ndk 等。一个配方由三部分组成详见 contrib/depends/packages.md1. 标识符必填$(package)_version # 上游版本无版本概念时可用 1.0 占位 $(package)_download_path # 上游源码位置不含文件名 $(package)_file_name # 下载路径下的源文件名 $(package)_sha256_hash # 源文件的 sha256 校验和可选标识符包括$(package)_build_subdir # 执行 configure/build/stage 前 cd 到的子目录 $(package)_download_file # 上游文件名与本地存储名不同时的本地名 $(package)_dependencies # 依赖的其他包名 $(package)_patches # 构建所需补丁文件名存放于 patches/包名/ $(package)_extra_sources # 通过 fetch_cmds 额外抓取的文件2. 构建变量$(package)_set_vars在define $(package)_set_vars ... endef函数中追加或覆盖编译相关变量可用的核心变量包括_cc、_cxx、_objc、_objcxx、_ar、_ranlib、_libtool、_nm、_cflags、_cxxflags、_ldflags、_cppflags、_config_env、_build_env、_stage_env、_build_opts、_config_opts。所有变量都支持按 host、架构或两者同时加前缀做条件覆盖通用: $(package)_ccgcc 仅 Linux: $(package)_linux_ccgcc 仅 x86_64: $(package)_x86_64_ccgcc 仅 x86_64 Linux: $(package)_x86_64_linux_ccgcc同时支持 debug/release 后缀仅在对应构建类型下生效$(package)_cflags_release -O3 $(package)_cflags_i686_debug -g $(package)_config_opts_release --disable-debug默认所有构建视为 release除非用户设置DEBUG1。*_env系列变量用于给相应命令追加环境变量funcs.mk还会自动注入PKG_CONFIG_LIBDIR、PKG_CONFIG_PATH、CMAKE_MODULE_PATH以及指向 native 工具目录的PATH。以 contrib/depends/packages/boost.mk 为实例它声明了boost_version1.91.0-1、下载路径、sha256_hash与补丁no-embed-absolute.patch在set_vars中按平台设置target-osandroid/darwin/windows、threadapipthread/win32、address-model32/64并在preprocess_cmds中生成user-config.jam注入交叉编译器与 flags——这是理解真实配方的最佳范本。3. 构建命令六个阶段每个包有独立且唯一的 build 目录与 staging 目录形如work/build/mylib/1.0-1adac830f6e、work/staging/mylib/1.0-1adac830f6eid 即 build-id 前 11 位见 contrib/depends/Makefile 的HASH_LENGTH:11六个阶段命令依次为命令运行目录默认行为$(package)_fetch_cmdsbuild 目录抓取源文件未定义时自动抓取并校验哈希$(package)_extract_cmdsbuild 目录校验哈希并解压未定义时假定源为 tar 包$(package)_preprocess_cmdsbuild 目录/_build_subdir源码预处理如打补丁默认无操作$(package)_config_cmdsbuild 目录/_build_subdir配置源码默认无操作$(package)_build_cmdsbuild 目录/_build_subdir编译默认无操作$(package)_stage_cmdsbuild 目录/_build_subdir安装到 staging默认无操作配方内可直接使用以下路径变量$(1)_staging_dir # 包的 sysroot 目标路径 $(1)_staging_prefix_dir # staging 内的 prefix 路径 $(1)_extract_dir # 解压后的源码路径 $(1)_build_dir # configure/build/stage 实际执行路径 $(1)_patch_dir # 包补丁所在路径对于 autotools 项目funcs.mk提供的$($(package)_autoconf)宏会拼出形如./configure --build$(BUILD) --host... --prefix... --with-pic ... CC... CXX...的完整配置命令并自动附加--disable-dependency-tracking、NM/RANLIB/AR/CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS大多数 autotools 项目可用如下命令完成 staging$(MAKE) DESTDIR$($(package)_staging_dir) installCMake 系项目则可借助$($(package)_cmake)宏它会注入CC/CXX/CFLAGS/LDFLAGS环境变量、CMAKE_INSTALL_PREFIX并在交叉编译时自动追加CMAKE_SYSTEM_NAME与CMAKE_C/CXX_COMPILER_TARGET。九、构建流水线从源码到缓存包的完整链路结合 contrib/depends/funcs.mk 的int_add_cmds与stages定义一个包的完整生命周期为fetched → extracted → preprocessed → configured → built → staged → postprocessed → cached → cached_checksumfetched下载源码并用build_SHA256SUM记录校验extracted校验哈希并解压到extract_dirpreprocessed复制补丁到patch_dir并执行预处理configured先清空host_prefix把全部递归依赖的缓存 tar 解压进去再执行配置命令built执行编译staged执行安装并删除extract_dirpostprocessed执行收尾如 boost 在 release 下裁剪不需要的头文件目录cached把 staging 内容打成 tar.gz 放入BASE_CACHE随后删除 staging 目录cached_checksum为缓存包生成 sha256 校验文件。Makefile 还会生成check-packages/check-sources目标用于缓存与源码的完整性校验校验失败即强制重下/重建并支持make print-变量名如make print-all_packages调试任意变量。顶层install目标在全部包完成后基于toolchain.cmake.in经 sed 替换生成$(host_prefix)/share/toolchain.cmake从而完成依赖 → 工具链的闭环。十、扩展新依赖最小改动三步走若需为 Monero depends 体系新增第三方库参照 contrib/depends/packages.md 的流程在 contrib/depends/packages/ 新建mylib.mk声明必填标识符version / download_path / file_name / sha256_hash与可选字段dependencies、patches、build_subdir 等并在set_vars中按平台/架构/debug-release 设定编译变量如需补丁放入 contrib/depends/patches/ 下以包名命名的子目录并在配方中通过$(package)_patches引用在 contrib/depends/packages/packages.mk 的packages/native_packages列表或按wallet_packages、readline_packages等分组中加入该包名。加入后运行make系统会自动完成哈希校验、依赖排序、build-id 计算与缓存分发无需手工处理各平台的下载与配置细节源码、缓存与补丁的完整链路均可通过make print-包名_xxx验证。十一、常见问题与排查技巧只想为当前平台构建不想指定 HOST直接makeHOST由config.guess自动探测下载超时或上游不可达设置FALLBACK_DOWNLOAD_PATH指向可达镜像默认官方downloads.getmonero.org/depends-sources下载连接超时与重试次数在 Makefile 中分别为DOWNLOAD_CONNECT_TIMEOUT:30秒与DOWNLOAD_RETRIES:5改了包配方却未触发重建检查 build-id 机制——只要配方文件或递归依赖哈希变化系统必然重建若仍异常可手动清除BASE_CACHE下对应包目录或运行make check-packages触发校验与强制重下MinGW 链接报线程模型错误确认已按第六节执行update-alternatives切换到 posix 模式调试单包depends 为每包暴露了分阶段目标如make boost_staged、make boost_cached可在不重跑全量的情况下单独构建与排查某个依赖。延伸阅读contrib/depends/description.mddepends 系统总体设计说明确定性、缓存、校验机制contrib/depends/packages.md新增依赖包的完整编写规范contrib/depends/Makefile选项定义、build-id 计算、toolchain.cmake 生成与 download 目标contrib/depends/funcs.mk构建阶段、路径变量、autoconf/cmake 辅助宏的底层实现contrib/depends/toolchain.cmake.in生成交叉工具链文件的 CMake 模板赞分享区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载相关推荐Dogecoin 跨平台依赖构建系统depends实战指南从零编译多平台依赖与交叉编译配置Dogecoin 跨平台依赖构建系统depends实战指南从零编译多平台依赖与交叉编译配置 本文以 Dogecoin 仓库中的 depends 系统说明区块链Zcash 可复现依赖构建系统 depends跨平台交叉编译与确定性缓存的工程实践Zcash 可复现依赖构建系统 depends跨平台交叉编译与确定性缓存的工程实践 导读 Zcash 的 depends 是一套独立于主工程之外的依赖构建与缓区块链金融科技密码学后端Zcash depends 依赖构建系统详解交叉编译、缓存机制与包配方实战Zcash depends 依赖构建系统详解交叉编译、缓存机制与包配方实战 本篇技术指南聚焦 Zcash 仓库中 depends/ 目录所实现的依赖构建系统区块链金融科技密码学后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考