安装

Windows/aarch64 版 R 与 x86_64（64 位 Intel 机器）的主要发行版分开发行。有一个适用于 Windows/aarch64 的 R 特殊安装程序。从用户角度来看，它与 x86_64 的安装程序几乎相同。aarch64 上的 R 需要 Windows 11。

R 安装程序构建预计会出现在 CRAN 页面上，但现在可以从 临时位置下载，其中目前包括 R 4.4 预发布版本和 R-devel 的每日版本。

安装程序本身是一个 x86_64 应用程序，它在 Windows/aarch64 上运行，由操作系统透明地模拟给用户。目录布局略有不同，因为不使用 R“子架构”。因此，例如 Rgui.exe 直接位于 bin 中，而它在 x86_64 上位于 bin/x64 中。

安装程序可以从 R 源代码在 Windows/aarch64 上以本机方式构建，就像可以在 x86_64 上构建 x86_64 的安装程序一样。通过上述 URL 提供的安装程序是在现有的 x86_64 基础架构上交叉编译的：本机代码使用 Linux/x86_64 上的 Rtools44 交叉编译，包括安装程序在内的其余部分在 Windows/x86_64 上构建。

R 默认安装在 Program Files/R-aarch64 中（与 x86_64 构建的 Program Files/R 不同），默认库目录名为 aarch64-library（与 x86_64 构建的 win-library 不同）。这是为了允许与 x86_64 构建并行安装，后者可以通过模拟在 Windows/aarch64 上运行。

在撰写本文时，x86_64 版本在模拟器中运行时未通过其安装测试，原因是存在数值差异。aarch64 通过了测试，此外，与在模拟器中运行相比，它确实有望具有更好的性能和更低的功耗。

在 Windows/aarch64 上使用 R 应被视为实验性的，包括本机版本和模拟的 x86_64 版本。Windows/aarch64 的本机支持在 R 包中仍然有限（更多信息见下文）：一些包和外部软件仍需要进行调整。R 尚未在 Windows/aarch64 上使用 CRAN 或 Bioconductor 包进行测试，无论是本机测试还是通过 x86_64 模拟测试。这与 x86_64 不同，CRAN 对 R 包进行定期和频繁的测试，也间接测试了 R 本身。

在 Windows/aarch64 上构建 R 已记录在 如何：在 Windows 上构建 R 4.4 和包 中。

Rtools

Rtools44 包含适用于 Windows/aarch64 的安装程序和工具链/库 tarball（完整版、基本版、交叉编译器、Tcl/Tk 捆绑包），镜像了为 Windows/x86_64 提供的常规组件。它们可从 CRAN 获得。更高版本的 Rtools43 已包含针对 aarch64 的未发布临时构建，用于与 R 的开发版本进行测试，这些构建可从临时位置获得。

Rtools44 基于 LLVM 17，并具有 Intel 版本中提供的几乎所有库。它使用 LLVM 链接器 (lld)、资源编译器和 C++ 库 (libc++)，而不是 binutils 和 libstdc++。需要 LLVM，因为 GCC 不支持 Windows/aarch64。

Rtools44 安装程序是一个 x86_64 应用程序，可以在模拟器中运行 Windows/aarch64。默认情况下，Rtools44 安装在 rtools44-aarch64 中（与 x86_64 构建的 rtools44 不同），以便允许这两个安装在 Windows/aarch64 上共存。对于以 aarch64 为主要平台的包开发人员来说，拥有 x86_64 版本可能很有用。R 安装程序构建将自动使用正确的 Rtools：通过安装程序安装的 aarch64 版 R 将使用 aarch64 版 Rtools，x86_64 版 R 将使用 x86_64 版 Rtools。

请注意，在从安装程序并行安装 Rtools 时，由于 Rtools 应用程序完全独立，因此即使是 Rtools 的 Msys2 部分也会出现两次。Rtools 的 Msys2 部分由构建工具组成，这些工具当前针对 x86_64 构建，并在模拟器中运行。与 Rtools42 一样，用户还可以从工具链+库 tarball 安装 Rtools，并维护一个单独的、带有构建工具的 Msys2 安装，以便与不同版本的 Rtools 工具链+库（例如 x86_64 Rtools43、x86_64 Rtools44 和 aarch64 Rtools44）配合使用。

安装包

在撰写本文时，CRAN 并未分发 aarch64 的二进制包。所有包都必须从源安装，就像在 Linux 上一样。当 R 从 macOS 的源代码构建时，这也是默认情况（CRAN 构建的 R 使用 CRAN 的二进制包）。

对于仅在 R 中实现的包来说，这几乎没有区别：只有安装时间略长，因为包是字节编译的，并准备用于延迟加载。二进制包只需要解压缩，这通常会更快。

但是，现在用户在需要安装任何“需要编译”（因此包括 C、Fortran 或 C++ 代码）的包时，都必须安装 Rtools。安装这些包所需的时间将比安装二进制版本时长得多。不过，这并不会让使用变得更困难：可以接受默认设置安装 Rtools，无需配置。基本包和推荐包已经是 R 二进制发行版的一部分，因此不需要为这些包安装 Rtools。并行安装可在多核系统上显著提升性能。

不过，预计一些包将无法从源安装，要么是因为它们需要调整，要么是因为它们需要一些尚未针对该平台提供的外部软件。

移植和测试包

在理想情况下，即使需要编译的包也不需要任何更改：可移植的、符合标准的 C、Fortran 和 C++ 代码应该可以正常工作，在许多情况下，CRAN 和 Bioconductor 包就是这样做的。此外，CRAN 包已经在 macOS 和 Linux 上使用 LLVM clang 进行了测试，并在 Linux 上使用 LLVM flang-new 进行了测试，因此意外对平台/编译器做出假设的代码应该已经大部分被检测到。LLVM 也支持许多 GCC 编译器扩展。

在理想情况下，仔细编写以遵循 编写 R 扩展 和 CRAN 存储库策略 的软件包在链接到外部库时也应正常工作，甚至无需更改链接/make 文件，而且许多软件包确实如此。此类软件包使用来自 Rtools（而不是下载预编译版本）的库，并且这些库的名称几乎始终与 x86_64 的名称相同。当 R 已提供抽象出差异的宏（BLAS、LAPACK、OpenMP、Fortran 运行时）时，名称有所不同。这些宏已记录在案，并建议在编写 R 扩展时使用，因此可移植软件包已在使用这些宏。软件包可以在 Rtools 中使用 pkg-config，这应降低软件包作者在 Rtools 更新方面的维护成本，但它与 aarch64 支持无关，也不需要 aarch64 支持。

在实践中，在单个架构上进行测试时很容易忽视一些可移植性问题 - 并且一些软件包代码是 Windows 特定的，因此到目前为止仅使用 GCC 和英特尔 CPU 进行了测试。已向 CRAN 和 Bioconductor 软件包维护者提供了近 100 个补丁，以修复其软件包，以便在 Windows/aarch64 上构建并通过检查。其中许多是上述类型易于修复的问题（从当前/相应标准中删除的 C++ 特性、GCC 特定的编译器选项、明确命名与 GCC 一起使用的 OpenMP 运行时、由于在系统头之前使用 R 头而导致的命名冲突、C/C++ 编译器比 GCC 更严格，因此发现了以前未发现的问题）。有些情况需要更多工作。

R 生态系统的一个长期问题是 R 软件包在构建时（R CMD INSTALL）下载预编译代码（静态库）。一些软件包正在执行此操作，尽管 Rtools 具有必需的库，甚至在 Rtools 具有较新版本时也执行此操作。在 CRAN 上，这是不允许的（它违反了 CRAN 存储库策略）。显然，此类代码在针对 x86_64 预编译时肯定无法在 aarch64 上运行。所提供的一些补丁只是紧急热修复程序，在非英特尔平台上禁用下载并回退到从源代码编译或使用 Rtools 中的库。推荐的方法是从 Rtools 使用库，如果那里没有，则通过上游 MXE 提供构建配置。

许多软件包无法在 Windows/aarch64 上运行，因为它们链接到由外部安装的软件提供的库，而此类软件有时尚未准备就绪（已移植或打包）。在撰写本文时，这包括 Java、MPI（Microsoft MPI 不支持 aarch64）和 JAGS 等重要软件。随着该平台变得越来越流行，这种情况可能会得到改善，事实上，R 并不孤单，其他开源项目也在适应以支持 Windows/aarch64。

此进度有时也会推动升级需求，一些 Rtools 库必须更新到支持 Windows/aarch64 的较新版本。一个需要 CRAN 软件包作者配合的情况是英特尔 TBB（线程构建模块）。它是 Rtools（x86_64 和 aarch64）的一部分，但许多 CRAN 软件包使用嵌入在另一个 CRAN 软件包中的较旧版本。然而，无法为 Windows/aarch64 构建该较旧版本。新版本在 API 中进行了多次重大更改，软件包必须进行更新。

另一个案例是 MinGW-W64：为 aarch64 构建的实验性 Rtools43 版本有条件地使用了较新版本的 MinGW-W64 以避免 aarch64 上的一些问题，但这需要调试和修复软件包中的命名冲突。无论是否使用 aarch64，都必须修复这些冲突。Rtools44 现在在两个平台上都使用较新版本的 MinGW-W64。

幸运的是，CRAN 和 Bioconductor R 软件包包含（并无条件使用）英特尔汇编代码的情况极为罕见。对于不受支持的平台，此类案例应该自动回退到可移植 C 代码。由于放弃了 aarch64 无法使用的亲手编写的汇编代码，许多 Rtools 库本身都是为 aarch64 构建的。

由于 LLVM 的 flang-new 编译器的限制，一些 CRAN 软件包无法为 Windows/aarch64 编译。

硬件可用性

没有功能强大的 64 位 ARM 笔记本电脑可以原生运行 Windows，但在 2023 年 10 月，高通宣布了其新的 64 位 ARM“骁龙精英 X”平台，集成了“猎户座”，预计电脑将于 2024 年年中上市。该公司将在 4 月 24 日（R 4.4 发布之日）发表进一步声明。不难找到基于此平台猜测即将推出的系统的文章。不难找到在测试系统上针对 Apple M3 测量的基准测试结果，通常声称性能相当，因此似乎取得了一些进展。

64 位 ARM 处理器已在服务器系统中使用 3 年（Ampere Computing 的 Ampere Altra）。还可以购买基于这些处理器的开发人员/原型设计工作站（AADP）。尽管有一些服务器硬件可用于在 ARM 上运行 Windows，但 Microsoft 尚未发布 Windows 服务器操作系统。目前，需要使用 Windows 11（并且可能需要弄清楚如何在服务器系统中根据许可证执行此操作）。

在 Apple Silicon 机器上工作的 R 包开发人员现在可以在 UTM/QEMU（或 Parallels）中运行的 Windows 11 上测试其包。此类开发人员可能希望在 Windows 上测试和调试其包，并且在他们的机器上使用 Windows 的 aarch64 版本将是自然的（撰写本文时，操作系统模拟器不支持完整的虚拟机，并且无论如何，首选本机运行）。常规 macOS R 用户自然会在 macOS 上本机运行 R，但如果由于某种原因他们被迫使用 Windows，那么它将再次成为 aarch64 上的 Windows。

为包开发人员做好准备

在平台实际普及之前开发新平台的软件很常见且有必要，因为开发过程需要很长时间。这就是为什么在平台编译器可用后立即开始 R 和 Rtools 的这项工作的原因，特别是当 LLVM flang-new 编译器变得足够稳定以构建基本 R 和推荐的包时。R 并不是唯一的，显然有人致力于使开源软件支持 Windows/aarch64，例如该平台已经有了 Python。

适用于 Windows/aarch64 的 R 和 Rtools 现在足够稳定，可以将 R 包开发/移植到该平台，如果 R 应该成为该平台上可行的选项，则需要这样做。大多数修复将需要使包更具可移植性和符合标准，这本身就是一件好事，并且会简化维护和对其他未来平台或编译器的潜在支持。对于具有大量反向依赖项的包的维护者来说，这一点尤其重要。

测试适用于 Windows/aarch64 的包的最简单方法可能是仍然在 Apple Silicon 硬件上的虚拟机中运行 Windows 11。Microsoft 甚至建议这样做，它记录在 Parallels 和 QEMU（UTM）中可以工作。通过 UTM/QEMU 完成 R/Rtools 的工作。对于 R 包开发人员来说，以这种方式本机使用 Windows 应该很容易：操作系统和 R 的工作方式几乎与他们习惯的方式相同。性能与在英特尔笔记本电脑上进行类似工作相当。

间接替代方法可以涵盖一些情况，但技术上更为复杂，即使用 Rtools44 交叉编译器在 Linux/x86_64 上测试编译。这仅适用于安装过程简单的软件包，但当寻找 LTO 检测到的代码中的问题时，以前曾使用过此方法。Rtools 中的交叉编译器本身应该经过充分测试，因为 Rtools 库本身是交叉编译的。此外，现在针对 aarch64 的 R 安装程序是交叉编译的，即使经过最少测试也是如此。但是，限制在于未针对交叉编译设计的 R 软件包。此外，这只会测试本机代码的编译。

aarch64 支持已部分集成到用于测试 Rtools 开发版本 (“ucrt3”) 的基础设施中，并且由此产生的软件包构建输出 可用于 CRAN 和一些 Bioconductor 软件包。这些测试使用该网站上也提供的补丁对软件包进行修补，这些补丁已提供给软件包维护者，并且在并入软件包后将从该网站中删除。安装测试仅偶尔运行，并且可能远远落后于当前 CRAN 源软件包存储库。

在撰写本文时，Windows/aarch64 没有 GitHub Actions 运行器支持，可在此处 跟踪。