本指南介绍了 R 的安装和管理。
本手册适用于 R 版本 4.3.3 (2024-02-29)。
版权所有 © 2001–2023 R 核心团队
允许制作和分发本手册的逐字副本，前提是在所有副本上保留版权声明和本许可声明。
允许在逐字复制的条件下复制和分发本手册的修改版本，前提是整个派生作品在与本许可声明相同的许可声明条款下分发。
允许在上述修改版本的条件下复制和分发本手册的翻译版本，但本许可声明可以以 R 核心团队批准的翻译版本的形式表示。
R 的源代码、二进制文件和文档可以通过 CRAN 获取，即“综合 R 档案网络”，其当前成员列表位于 https://CRAN.R-project.org/mirrors.html。
最简单的方法是下载最新的 R-x.y.z.tar.gz 文件，并使用以下命令解压缩：
tar -xf R-x.y.z.tar.gz
在安装了合适1 tar 的系统上。在其他系统上，您需要安装 gzip 程序，然后可以使用以下命令：
gzip -dc R-x.y.z.tar.gz | tar -xf -
解压缩源代码的目录路径中不应包含空格，因为大多数 make 程序（特别是 GNU make）不希望出现空格。
如果您希望构建结果可供一组用户使用，请在解压缩之前设置 umask，以便目标组（例如，umask 022，可供所有用户使用）可以读取这些文件。在构建和安装过程中保持此 umask 设置。
如果您使用的是相当新的 GNU 版本的 tar，并且以 root 帐户（在 Windows 上包括具有管理员权限的帐户）执行此操作，您可能会看到许多关于更改所有权的警告。在这种情况下，您可以使用以下命令：
tar --no-same-owner -xf R-x.y.z.tar.gz
并且可能还需要包含选项 --no-same-permissions。 （这些选项也可以在 TAR_OPTIONS 环境变量中设置：如果包含多个选项，则应使用空格分隔。）
当前版本的修补版本，‘r-patched’，以及当前的开发版本，‘r-devel’，可以作为每日的tar包，也可以通过访问R Subversion仓库获取。（在发布次要版本（4.x.0）之前的两周内，‘r-patched’ tar包可能指的是即将发布的版本的beta/发布候选版本，当前版本的修补版本可以通过Subversion获取。）
tar包可以从 https://stat.ethz.ch/R/daily/ 获取。下载 R-patched.tar.gz 或 R-devel.tar.gz（或 .tar.bz2 版本）并按照上一节的描述解压。它们以与R发布版本完全相同的方式构建。
源代码也可以通过 https://svn.R-project.org/R/ 获取，即R Subversion仓库。如果您有Subversion客户端（参见 https://subversion.org.cn/），您可以从 https://svn.r-project.org/R/trunk/ 检查并更新当前的‘r-devel’，以及从‘https://svn.r-project.org/R/branches/R-x-y-branch/’（其中x和y是当前发布的R版本的版本号）检查并更新当前的‘r-patched’。例如，使用
svn checkout https://svn.r-project.org/R/trunk/ path
将‘r-devel’检出到目录path（如果需要，将创建该目录）。即将发布的x.y.0版本的alpha、beta和RC版本可以在发布前四周内从‘https://svn.r-project.org/R/branches/R-x-y-branch/’获取。
请注意，需要使用‘https:’2，并且R项目的Subversion服务器的SSL证书应被识别为来自可信来源。
请注意，通过例如 wget -r 或 svn export 从该URL获取源代码将不起作用（并且将在 make 过程的早期阶段出现错误）：构建R需要Subversion信息。
Subversion 仓库不包含推荐包的当前源代码，可以通过 rsync 获取或从 CRAN 下载。要使用 rsync 安装推荐包的适当源代码，请从 R 源代码的顶层目录运行 ./tools/rsync-recommended。
如果从 CRAN 手动下载，请确保您拥有推荐包的正确版本：如果文件 VERSION 中的数字是 ‘x.y.z’，则需要下载 ‘https://CRAN.R-project.org/src/contrib/dir’ 的内容，其中 dir 是 ‘x.y.z/Recommended’（用于 r-devel）或 x.y-patched/Recommended（用于 r-patched），分别到解压缩的源代码中的 src/library/Recommended 目录。手动下载后，您需要从源代码的顶层执行 tools/link-recommended 以在 src/library/Recommended 中创建必要的链接。从 R 源代码的顶层使用 wget 的一个合适的命令可能是（对于 dir 的正确值）：
wget -r -l1 --no-parent -A\*.gz -nd -P src/library/Recommended \ https://CRAN.R-project.org/src/contrib/dir ./tools/link-recommended
R 可以在大多数常见的 Unix 和类 Unix 平台上进行配置和构建，包括 ‘cpu-*-linux-gnu’（适用于 ‘alpha’、‘arm64’（也称为 ‘aarch64’、‘ix86’、‘mips’、‘mipsel’#, ‘ppc64’、‘riscv64’、‘s390x’、‘sparc64’ 和 ‘x86_64’ CPU）、‘x86_64-apple-darwin’ 和 ‘aarch64-apple-darwin’3，以及可能（这些平台上的测试频率较低）‘x86_64-*-freebsd’、‘x86_64-*-openbsd’ 和 ‘powerpc-ibm-aix6*’
此外，一些常见的 Linux 发行版（有关最新详细信息，请参阅 FAQ）和 macOS 提供了二进制发行版。这些发行版以特定于平台的方式安装，因此在本章的其余部分中，我们只考虑从源代码构建。
交叉编译是不可能的：安装 R 会构建一个最小版本的 R，然后运行许多 R 脚本以完成构建。
首先，查看 类 Unix 系统下必不可少且有用的其他程序 中的必要工具和库，并安装您想要或需要的工具和库。确保环境变量 TMPDIR 处于未设置状态（并且 /tmp 存在且可以写入，并且可以从该目录执行脚本）或指向有效临时目录的绝对路径（允许从该目录执行脚本的目录），该目录不包含空格。4
选择一个目录来安装 R 树（R 不仅仅是一个二进制文件，它还包含额外的数据集、帮助文件、字体度量等）。我们将其称为 R_HOME。解压缩源代码。这将在顶级目录下创建目录 src、doc 以及其他几个目录：切换到该顶级目录（此时，北美读者应参考 设置纸张大小。）执行以下命令
./configure make
（如果您的 make 不是名为 ‘make’ 的，请参阅 使用 make。）基于 Debian 的 64 位系统用户5 可能需要
./configure LIBnn=lib make
然后通过以下命令检查构建的系统是否正常工作
make check
失败并不一定代表问题，因为它们可能是由于缺少功能造成的，但您应该仔细查看任何报告的差异。（在不支持 Latin-1 的区域设置中，一些非致命错误是预期的，特别是在真正的 C 区域设置和非 UTF-8 非西欧区域设置中。）tests/ok-errors.R 中的失败可能表明资源限制不足（请参阅 运行 R）。
可以通过以下方式进行更全面的测试：
make check-devel
或
make check-all
参见 测试安装 以了解并行执行此操作的可能性。请注意，只有在安装了推荐的软件包后才会完全运行这些检查。如果您有本地 CRAN 镜像，可以通过设置环境变量 R_CRAN_WEB 为其 URL，或在文件 .R/repositories 中指定它来加快这些检查的速度（参见 ?setRepositories）。
并行 make 支持构建 R，但不支持“check”目标（因为输出很可能无法读取地交织在一起，尽管在支持的情况下6 GNU make 的 -O 可能会有所帮助）。
如果 configure 和 make 命令成功执行，将创建一个名为 R 的 shell 脚本前端，并将其复制到 R_HOME/bin。您可以将此脚本链接或复制到用户可以调用它的位置，例如 /usr/local/bin/R。您也可以将手册页 R.1 复制到 man 阅读器可以找到的位置，例如 /usr/local/man/man1。如果您想将完整的 R 树安装到，例如，/usr/local/lib/R，请参见 安装。注意：您不需要安装 R：您可以从构建它的位置运行它。
您不必一定在顶层源目录（例如，TOP_SRCDIR）中构建 R。要在 BUILDDIR 中构建，请运行
cd BUILDDIR TOP_SRCDIR/configure make
等等，如下所述。这样做的好处是始终保持源树干净，尤其是在使用 Subversion 中的 R 版本时推荐这样做。（您可能需要 GNU make 来允许这样做，并且您需要在构建目录的路径中没有空格。如果源目录以前曾用于构建，则它不太可能工作。）
在构建 R 时，可以自定义许多设置，大多数设置在顶层源目录中的 config.site 文件中描述。可以编辑它，但对于使用 BUILDDIR 的安装，最好将更改的设置放在构建目录中新创建的文件 config.site 中。
现在，如果需要，请 rehash，键入 R，并阅读 R 手册和 R FAQ（文件 FAQ 或 doc/manual/R-FAQ.html，或 https://CRAN.R-project.org/doc/FAQ/R-FAQ.html，它始终包含最新 R 版本的版本）。
注意：如果您已经安装了 R，请检查您安装 R 的位置是否替换了或在您的路径中比以前的安装位置更早。某些系统设置为将 /usr/bin（系统安装的标准位置）放在 /usr/local/bin（安装 R 的默认位置）之前，而某些系统在默认路径中没有 /usr/local/bin。
默认情况下，R 提供以纯文本形式显示在分页器中的帮助页面，并提供以下选项（请参阅 help 的帮助信息）：以 HTML 或 PDF 格式显示帮助。
默认情况下，HTML 帮助页面在需要时创建，而不是在安装时构建。
如果您需要禁用服务器并需要 HTML 帮助，可以选择在安装软件包（包括与 R 一起安装的软件包）时构建 HTML 页面。这可以通过 configure 选项 --enable-prebuilt-html 启用。是否 R CMD INSTALL（以及 install.packages）预构建 HTML 页面取决于 R 安装，并由 R CMD INSTALL --help 报告：可以通过指定 INSTALL 选项之一 --html 或 --no-html 来覆盖它。
可以通过在启动 R 之前或在 R 会话中使用 HTML 帮助（包括 help.start）之前，将环境变量 R_DISABLE_HTTPD 设置为非空值来禁用服务器。系统安全措施也可能阻止服务器启动，例如，如果回环接口已禁用。有关更多详细信息，请参阅 ?tools::startDynamicHelp。
有一套手册可以从源代码构建，
所有基本包和推荐包的帮助页面的打印版本（约 3750 页）。
选定基本包的帮助页面的打印版本（约 2200 页）
R FAQ
“R 入门”。
“R 数据导入/导出”。
“R 安装和管理”，本手册。
“编写 R 扩展”。
“R 语言定义”。
要制作这些（使用 ‘fullrefman’ 而不是 ‘refman’），请使用
make pdf to create PDF versions make info to create info files (not ‘refman’ nor ‘fullrefman’).
除非您安装了 texi2any 版本 5.1 或更高版本，否则您将无法构建任何这些手册，并且对于 PDF，您必须安装 texi2dvi 和 texinfo.tex（这些是 GNU texinfo 发行版的一部分，但通常是 TeX 包的一部分，尤其是在重新分发时，例如 texinfo.tex）。可以通过 config.site 中的宏 ‘TEXI2ANY’ 设置 texi2any 的路径。注意：texi2any 需要 perl。
可以使用任何最新的 PDF 查看器查看 PDF 版本：它们具有可以跟随的超链接。info 文件适合使用 Emacs 或独立的 GNU info 程序在线阅读。PDF 版本将使用在配置时选择的纸张大小创建（默认 ISO a4）：这可以通过在 make 命令行上设置 R_PAPERSIZE ，或者在环境中设置 R_PAPERSIZE 并使用 make -e 来覆盖。 （如果要为不同的纸张大小重新制作手册，您应该首先删除文件 doc/manual/version.texi。北美通常的值是 ‘letter’。）
制作 PDF 参考手册 fullrefman.pdf 或 refman.pdf 时存在一些问题。帮助文件包含非 ASCII 字符（例如在 text.Rd 中）和直立引号，这些字符都不包含在标准 LaTeX Computer Modern 字体中。我们提供了以下替代方案
times(默认。) 使用标准 PostScript 字体，Times Roman、Helvetica 和 Courier。这对于屏幕查看和打印都非常有效。一个缺点是“用法”和“示例”部分可能会很宽：这可以通过使用 此外 选项 inconsolata（在类 Unix 系统上，只有在 configure 找到的情况下）或 beramono 来克服，它们分别用 Inconsolata 或 Bera Sans mono 替换 Courier 等宽字体。（您需要安装 LaTeX 包 inconsolata7 或 bera。）
请注意，在大多数 LaTeX 安装中，这实际上不会使用 PDF 的标准字体，而是嵌入 URW 克隆 NimbusRom、NimbusSans 和（如果使用 Courier）NimbusMon。
这需要安装 LaTeX 包 times、helvetic 和（如果使用）courier。
lm使用 Latin Modern 字体。这些字体通常不会作为 TeX 发行版的一部分安装，但可以从 https://www.ctan.org/tex-archive/fonts/ps-type1/lm/ 和镜像获取。这使用与 Computer Modern 相似的字体，但在屏幕上不如 times 好。
可以通过设置环境变量 R_RD4PDF 来覆盖默认值。（在类 Unix 系统上，这将在安装时被拾取并存储在 etc/Renviron 中，但仍然可以在构建手册时使用 make -e 覆盖。）R_RD4PDF 的通常8 默认值为 ‘times,inconsolata,hyper’：如果您没有安装 LaTeX 包 inconsolata，请省略 ‘inconsolata’。从 R 4.2.0 开始，‘hyper’ 始终启用（如果 LaTeX 包 hyperref 未安装，则使用备用方案）。
其他选项（例如 hyperref）可以包含在 LaTeX 搜索路径上的某个文件 Rd.cfg 中。例如，如果您希望在目录中链接文本而不是页码，请使用
\ifthenelse{\boolean{Rd@use@hyper}}{\hypersetup{linktoc=section}}{}
或
\ifthenelse{\boolean{Rd@use@hyper}}{\hypersetup{linktoc=all}}{}
来链接文本和页码。
任何生成的 PDF 手册都可以通过以下方式压缩
make compact-pdf
前提是 qpdf 和 gs 可用（有关如何指定它们（如果不在路径上），请参见 ?tools::compactPDF）。
大多数手册的电子书版本都可以通过在 doc/manual 目录下运行以下命令之一来生成，格式为 .epub 和/或 .mobi：
make ebooks make epub make mobi
这需要来自 Calibre 或大多数 Linux 发行版的 ebook-convert 命令。如果需要，可以通过编辑 doc/manual/Makefile (其中包含适合 macOS 的注释值) 或使用 make -e 命令将 ebook-convert 的路径设置为 make 宏 EBOOK。
为了确保安装的树可以被正确的用户组使用，在解压源代码和整个构建过程中，请适当地设置 umask (可能设置为 ‘022’)。
在
./configure make make check
(或者，在源代码外部构建时，为 TOP_SRCDIR/configure 等) 成功完成之后，您可以通过输入以下命令将完整的 R 树安装到您的系统中：
make install
可以使用并行 make (但在运行 make install 之前先运行 make)。使用 GNU make 4.0 或更高版本的用户可能希望使用 make -j n -O 来避免输出交错。
这将安装到以下目录：
前端 shell 脚本和其他脚本和可执行文件
手册页
所有其他内容 (库、在线帮助系统等)。这里 LIBnn 通常为 ‘lib’，但在某些 64 位 Linux 系统上可能为 ‘lib64’。这被称为 R 主目录。
其中 prefix 在配置期间确定（通常为 /usr/local），可以通过运行 configure 并使用选项 --prefix 来设置，例如
./configure --prefix=/where/you/want/R/to/go
其中该值应为绝对路径。这会导致 make install 将 R 脚本安装到 /where/you/want/R/to/go/bin 等位置。安装目录的前缀可以在 configure 结束时显示的状态消息中看到。安装可能需要由 prefix 的所有者（通常是 root 帐户）完成。
可以选择使用 make install-strip（参见 调试符号）。
您可以使用以下命令将文件安装到另一个目录树中：
make prefix=/path/to/here install
至少在使用 GNU make 时（但某些其他 Unix make 不支持）。
在配置时可以通过选项进行更精确的控制：有关详细信息，请参见 configure --help。（但是，大多数“安装目录的微调”选项不会被 R 使用。）
配置选项 --bindir 和 --mandir 受支持，并控制 R 脚本和 man 页面的副本的安装位置。
配置选项 --libdir 控制主要 R 文件的安装位置：默认值为“eprefix/LIBnn”，其中 eprefix 是用于安装与体系结构相关的文件的目录前缀，默认为 prefix，可以通过配置选项 --exec-prefix 设置。
每个 bindir、mandir 和 libdir 也可以在 make install 命令行上指定（至少在使用 GNU make 时）。
可以使用 configure 或 make 变量 rdocdir 和 rsharedir 将与系统无关的 doc 和 share 目录安装到 libdir 以外的位置。C 头文件可以安装到 rincludedir 的值：请注意，由于头文件没有安装到子目录中，因此您可能需要类似 rincludedir=/usr/local/include/R-4.3.3 的内容。
如果您希望 R 主目录不是 libdir/R，请使用 rhome：例如
make install rhome=/usr/local/lib64/R-4.3.3
将在非 Debian Linux 64 位系统上使用特定版本的 R 主目录。
如果您已将 R 作为共享/静态库构建，则可以通过以下方式将其安装到系统的库目录中：
make prefix=/path/to/here install-libR
其中 prefix 是可选的，而 libdir 将提供更精确的控制。9 但是，如果您打算使用多个版本的 R，则不应安装到 LDPATHS 中提到的目录（例如 /usr/local/lib64），因为该目录可能优先于其他 R 安装的 lib 目录。
make install-strip
将安装剥离的可执行文件，以及在支持此功能的平台上，剥离的库将安装在 lib 和 modules 目录以及标准包中。
请注意，不支持将 R 安装到路径包含空格的目录中，并且某些方面（例如安装源包）将无法正常工作。
要安装手册的 info 和 PDF 版本，请使用以下一个或两个命令：
make install-info make install-pdf
再次强调，指定 prefix、libdir 或 rhome 是可选的（PDF 手册安装在 R 主目录下）。
可以进行更精确的控制。对于 info，使用的设置是 infodir 的设置（默认值为 prefix/info，由配置选项 --infodir 设置）。PDF 文件安装到 R 的 doc 树中，由 make 变量 rdocdir 设置。
可以进行分阶段安装，即先将 R 安装到临时目录中，然后将安装的树移动到最终目标位置。在这种情况下，prefix（以及其他参数）应该反映最终目标位置，并且应该使用 DESTDIR：请参阅 https://www.gnu.org/prep/standards/html_node/DESTDIR.html。
您可以选择安装 make check-all 中包含的运行时测试，方法是：
make install-tests
它会在安装过程中填充一个名为 tests 的目录。
您可以通过以下方式卸载 R
make uninstall
可以选择性地指定 prefix 等，与安装时指定的相同。
这也会卸载任何已安装的手册。在文件 doc/manual/Makefile 中，有一些特定目标用于卸载信息和 PDF 手册。
目标 uninstall-tests 将卸载任何已安装的测试，以及删除包含测试结果的目录 tests。
已安装的共享/静态 libR 可以通过以下方式卸载
make prefix=/path/to/here uninstall-libR
某些平台可以支持密切相关的 R 构建，这些构建可以共享除可执行文件和动态对象之外的所有内容。例如，在 Linux 上为不同的 CPU 或 32 位和 64 位构建的构建。
R 支持特定于架构的构建的概念，通过在 configure 行中添加 ‘r_arch=name’ 来指定。这里 name 可以是任何非空字符串，用于命名 lib、etc、include 和包 libs 子目录的子目录。其他软件中的示例名称包括在 Sparc Solaris 上使用 sparcv9 以及在 ‘x86_64’ Linux 上使用 gcc 使用 32。
如果您有两个或多个这样的构建，您可以将它们相互覆盖安装（对于同一架构上的 32/64 位构建，可以不使用 ‘r_arch’ 完成一个构建）。节省的空间可能相当可观：在 ‘x86_64’ Linux 上，基本安装（不含调试符号）占用 74Mb，添加 32 位构建增加了 6Mb。如果您安装了多个构建，您可以通过以下方式选择要运行的构建
R --arch=name
只需运行 ‘R’ 将运行最后安装的构建。
R CMD INSTALL 将检测是否安装了多个构建，并尝试为每个构建安装具有适当库对象的包。如果包具有可执行的 configure 脚本或 src/Makefile 文件，则不会执行此操作。在这种情况下，您可以通过以下方式为其他构建安装
R --arch=name CMD INSTALL --libs-only pkg1 pkg2 ...
如果您想混合在不同平台上编译的子架构（例如“x86_64” Linux 和“i686” Linux），最好为每个子架构使用显式名称，并且您可能还需要设置 libdir 以确保它们安装到同一个位置。
当使用子架构时，例如 /usr/bin 中的 Rscript 版本将是最后安装的版本，但特定于架构的版本将在例如 /usr/lib64/R/bin/exec${R_ARCH} 中可用。通常，所有已安装的架构都将在平台上运行，因此 Rscript 本身的架构并不重要。可执行文件 Rscript 将运行 R 脚本，此时 R_ARCH 环境变量的 设置将决定运行的架构。
在使用子架构运行安装后测试时，请使用
R --arch=name CMD make check[-devel|all]
选择要检查的子架构。
子架构也用于 Windows，但通过选择适当的 bin 目录中的可执行文件，例如 R_HOME/bin/x64。为了向后兼容，存在可执行文件 R_HOME/bin/R.exe 和 R_HOME/bin/Rscript.exe：它们将运行来自子目录之一的可执行文件，哪个子目录首先从 R_ARCH 环境变量中获取，然后从 --arch 命令行选项10 中获取，最后从安装默认值（对于组合的 32/64 位 R 安装，默认值为 32 位）中获取。R 4.2.0 遵循此方案，但仅支持和包含 64 位构建。
对于某些 Linux 发行版11，存在一种混合 32 位和 64 位库的替代机制，称为 多库。如果 Linux 发行版支持多库，则 R 的并行构建可以安装在子目录 lib（32 位）和 lib64（64 位）中。然后可以使用 setarch 命令选择要运行的构建。例如，可以通过以下方式运行 32 位构建：
setarch i686 R
只有在安装了 32 位和 64 位构建时，setarch 命令才有效。如果只有一个 R 安装，则无论 setarch 命令指定的架构是什么，它都将始终运行。
在非原生架构上安装软件包可能会出现问题。即使只安装了一个版本的 R，在安装软件包的会话中运行例如 setarch i686 R 也是一个好主意（因为这会告诉软件包安装代码所需的架构）。
使用 Java 的软件包存在潜在问题，因为在 ' x86_64 ' Linux 上安装 ' i686 ' RPM 的后安装步骤会重新配置 Java 并找到 ' x86_64 ' Java。如果您知道 32 位 Java 的安装位置，您可以以 root 身份运行
export JAVA_HOME=<path to jre directory of 32-bit Java> setarch i686 R CMD javareconf
以获得合适的设置。
当使用这种机制时，例如 /usr/bin 中的 Rscript 版本将是最后安装的版本，但特定于架构的版本将在例如 /usr/lib64/R/bin 中可用。通常所有已安装的架构都可以在平台上运行，因此 Rscript 的架构并不重要。
还有许多其他安装选项，大多数选项都列在 configure --help 中。几乎所有在本手册中未列出的选项要么是与 R 无关的标准 autoconf 选项，要么是 R 开发人员用于专业用途的选项。
在开发 R 本身时可能有用的是选项 --disable-byte-compiled-packages，它确保基本包和推荐包不会被字节编译。（或者，可以在构建期间将（make 或环境）变量 R_NO_BASE_COMPILE 设置为非空值。）
选项 --with-internal-tzcode 使用 R 自身的代码和 IANA 数据库副本管理时区。如果系统实现存在问题，通常涉及 2037 年之后或 1916 年之前的日期，则首选此选项。可以使用环境变量 TZDIR 指向的备用时区目录12：该目录应包含诸如 Europe/London 之类的文件。在所有经过测试的操作系统上，系统时区都已正确推断，但如有必要，可以将其设置为环境变量 TZ 的值。
选项 --with-internal-iswxxxxx、--with-internal-towlower 和 --with-internal-wcwidth 在 R 4.1.0 中引入。这些选项控制用 R 源代码中包含的函数替换系统范围的宽字符分类（如 iswprint）、大小写转换 (wctrans) 和宽度 (wcwidth 和 wcswidth) 函数。多年来，在 macOS 和 AIX（以及 Windows）上已经对分类函数进行了替换：选项 --with-internal-iswxxxxx 允许在这些平台上抑制此操作或在其他平台上使用。替换大小写转换函数是 R 4.1.0 中的新功能，并且是 macOS（以及自 R 4.2.0 以来在 Windows 上）的默认设置。宽度函数的替换也已经进行了多年，并且仍然是默认设置。这些选项只对处理非 ASCII 字符数据的人员很重要，尤其是在使用非西方脚本13 的语言中（包括诸如表情符号之类的“符号”）。请注意，其中一个 iswxxxxx 是 iswprint，它用于决定是否将字符输出为字形或作为“\U{xxxxxx}”转义符——例如，尝试“"\U1f600"”，这是一个表情符号。宽度函数在东亚语言环境中最为重要：它们的值在这些语言环境之间有所不同。（替换系统函数提供了一定程度的平台独立性（包括对操作系统更新的独立性），但将其替换为对 R 版本的依赖。）
默认情况下，configure 会为 C、Fortran 和 CXX 源代码添加一个标志（通常为 -g）到编译标志中。这会减慢编译速度并增加 R 和包的对象大小，因此更改这些标志可能是一个好主意（在配置之前在 config.site 中设置 ‘CFLAGS’ 等，或者在运行 configure 和 make 之间编辑文件 Makeconf 和 etc/Makeconf）。
在使用调试器（例如，R -d gdb）运行 R 以及使用消毒剂和 valgrind 时，拥有可用的调试符号非常有用，所有这些都是为专家设计的。
调试符号（以及其他一些符号）可以在安装时使用以下命令“剥离”
make install-strip
此功能的支持程度取决于平台：在使用 GNU binutils 的平台上效果最佳。在 ‘x86_64’ Linux 上，总体大小通常从 92MB 减少到 66MB。在 macOS 上，调试符号默认情况下不会包含在 .dylib 和 .so 文件中，因此差异可以忽略不计。
默认情况下，configure 会搜索适合的标志14，用于为 C、C++（默认标准）和 Fortran 编译器提供 OpenMP 支持。
目前仅使用 C 的结果用于 R 本身，并且仅当未指定 MAIN_LD/DYLIB_LD 时。可以通过指定以下内容来覆盖此设置
R_OPENMP_CFLAGS
包的使用具有类似的限制（涉及 SHLIB_LD 等：请注意，由于 Fortran 代码默认情况下由 C（或 C++）编译器链接，因此两者都需要支持 OpenMP），可以通过指定以下内容来覆盖
SHLIB_OPENMP_CFLAGS SHLIB_OPENMP_CXXFLAGS SHLIB_OPENMP_FFLAGS
将这些值设置为空值将禁用该编译器的 OpenMP（并使用 --disable-openmp 配置将禁用所有 OpenMP 检测15）。configure 检测测试是编译和链接一个独立的 OpenMP 程序，这与编译共享对象并将其加载到 R 可执行文件的 C 程序中不同。请注意，不会测试覆盖的值。
R 本身不使用 C++，但通过 etc/Makeconf 文件中定义的 make 宏（以及 config.site 文件中的解释）为安装包含 C++ 代码的包提供支持。
CXX CXXFLAGS CXXPICFLAGS CXXSTD CXX11 CXX11STD CXX11FLAGS CXX11PICFLAGS CXX14 CXX14STD CXX14FLAGS CXX14PICFLAGS CXX17 CXX17STD CXX17FLAGS CXX17PICFLAGS CXX20 CXX20STD CXX20FLAGS CXX20PICFLAGS CXX23 CXX23STD CXX23FLAGS CXX23PICFLAGS
宏 CXX 等是默认用于 C++ 代码的宏。 configure 将尝试适当地设置其余部分，为 CXXSTD 和 CXX11STD 选择一个合适的标志，例如 -std=c++11 用于 C++11 支持（如果要支持 C++，则需要此支持）。 推断的值可以在 config.site 文件中或在 configure 命令行中覆盖：用户提供的将通过编译一些 C++11/14/17/20/23 代码进行测试。
可能默认编译器没有适合 C++14/17/20/23 支持的标志，在这种情况下，可以使用不同的编译器为 CXX14/CXX17/CXX20/CXX23 选择，并使用其相应的标志。
-std 标志受 GCC、clang++ 和 Intel 编译器支持。 当前接受的值为（以及一些同义词）
g++: c++11 gnu+11 c++14 gnu++14 c++17 gnu++17 c++2a gnu++2a (from 8)
c++20 gnu++20 (from 10) c++23 gnu++23 c++2b gnu++2b (from 11)
Intel: c++11 gnu+11 c++14 gnu++14 c++17 gnu++17
c++20 gnu++20 (from 2021.1) c++2b gnu++2b (from 2022.2)
（LLVM clang++ 的那些在 https://clang.llvm.org/cxx_status.html 中有记录，并遵循 g++：-std=c++20 从 Clang 10 开始支持，-std=c++2b 从 Clang 13 开始支持，-std=c++23 从 Clang 17 开始支持。 Apple Clang 从 13.1.6 开始支持 -std=c++2b：版本 15.0.0 不支持 -std=c++23。）
以 ‘gnu’ 开头的 g++ 的“标准”启用“GNU 扩展”：很难追踪到这些是什么。
有关在 R 包中使用 C++11 及更高版本的信息，请参阅“编写 R 扩展”手册。 在 R 3.6.0 之前，默认的 C++ 标准是所用编译器的标准：目前是 C++17（如果可用）：这可以通过在配置 R 时设置 ‘CXXSTD’ 来覆盖。
https://cppreference.cn/w/cpp/compiler_support 指示了常见编译器的哪些版本支持（部分）哪些 C++ 标准。 GCC 5 是具有足够 C++14 支持的最低版本。 GCC 逐步引入了 C++17 支持，但版本 7 应该足够。
编译 R 需要 C99 或更高版本：C11 和 C17 是小幅更新，但计划于“C23”进行的重大更新（预计将于 2024 年 4 月左右发布）也将得到支持。
从 R 4.3.0 开始，支持包来指示其首选的 C 版本。宏 CC17、C17FLAGS、CC23 和 C23FLAGS 可以设置在 config.site 中（其中有示例）。C17 的宏应该支持 C17 或更早版本，并且不允许使用 C23 的新增内容，例如 bool、true 和 false 可以用作标识符。C23 的宏应该支持新的类型，例如 bool。
一些编译器会热心地发出关于原型声明的警告。对于大多数编译器来说，在 C17FLAGS 中省略 -Wstrict-prototypes 就足够了。但是，LLVM clang 的 15 及更高版本以及 Apple clang 的 14.0.3 及更高版本在所有模式下默认情况下都会发出警告，如果使用了 -Wall 或 -pedantic，则可能需要使用 -Wno-strict-prototypes。
如果工具链支持链接时优化（LTO），则支持使用链接时优化：使用标志 --enable-lto 进行配置。当启用 LTO 时，它将用于附加包中编译的代码，除非使用标志 --enable-lto=R16。
迄今为止，从 LTO 中看到的主要好处是检测到包传递给编译代码以及在编译单元之间传递参数的方式中长期存在的错误。2020 年使用 gcc/gfortran 10 进行的基准测试表明，对于没有调试符号的构建，性能提高和安装大小减少了几个百分点，但对于某些具有调试符号的包17，大小大幅减少。（据说性能和大小增益最常在复杂的 C++ 构建中看到。）
工具链是否支持 LTO 通常不清楚：C 编译器、Fortran 编译器18 和链接器都必须支持它，并且通过相同的机制支持它（因此混合编译器系列可能无法工作，可能需要非默认链接器）。GCC 和 LLVM 项目多年来一直支持它，但实现方式有所不同。
2011 年为 Linux 上的 GCC 4.5 添加了 LTO 支持，但在 2019 年之前使用很少：这些年来编译器支持一直在稳步改进，如今 --enable-lto=R 用于一些例行的 CRAN 检查。
不幸的是，--enable-lto 可能会被接受，但如果工具链中的某些部分不支持 LTO，则可能默默地不执行任何有用的操作：这种情况比以前少见。
可以在文件 config.site 中设置各种宏来定制 LTO 的使用方式。如果 Fortran 编译器与 C/C++ 编译器不属于同一系列，请设置宏 ‘LTO_FC’（可能为空）。宏 ‘LTO_LD’ 可用于选择备用链接器（如果需要）。
这已在 Linux 上使用 gcc/gfortran 8 及更高版本进行了测试：这需要设置（例如在 config.site 中）
AR=gcc-ar RANLIB=gcc-ranlib
对于非系统编译器，或者如果这些包装器尚未安装，则可能需要类似的东西
AR="ar --plugin=/path/to/liblto_plugin.so" RANLIB="ranlib --plugin=/path/to/liblto_plugin.so"
amd NM 可能需要类似地设置。（如果使用支持 LTO 的构建来检查包，请将环境变量 UserNM19 设置为 ‘gcc-nm’。）
使用 GCC 5 及更高版本，可以并行化 LTO 链接过程的某些部分：将 make 宏 ‘LTO’ 设置为类似 ‘LTO=-flto=8’ 的内容（使用 8 个线程），例如在文件 config.site 中。
在某些情况下，对于一些包，在 Linux 上使用 GCC 9 及更高版本时，需要覆盖 PIC 标志：例如在 config.site 中使用
CPICFLAGS=-fPIC CXXPICFLAGS=-fPIC CXX11PICFLAGS=-fPIC CXX14PICFLAGS=-fPIC CXX17PICFLAGS=-fPIC CXX20PICFLAGS=-fPIC FPICFLAGS=-fPIC
我们建议仅在遇到问题时使用这些标志（在撰写本文时，在 CRAN 上使用 GCC 10 时没有看到此问题）。
请注意，即使对编译器进行了较小的更新（例如从 10.1 更新到 10.2），也可能需要重新编译 R，但这可能无法从混乱的编译器消息中清楚地看出。
LLVM 支持另一种类型的 LTO，称为“瘦 LTO”，以及与 GCC 类似的实现，有时称为“完整 LTO”。（参见 https://clang.llvm.org/docs/ThinLTO.html。）目前与 R 相关的 LLVM 编译器是 clang 和 flang，可以通过设置宏 ‘LTO=-flto=thin’ 来选择。LLVM 有
AR=llvm-ar RANLIB=llvm-ranlib
（但 macOS 没有，而且在那里不需要）。如果链接器支持用于瘦 LTO 的并行后端，则可以通过宏 ‘LTO_LD’ 指定：有关每个链接器的设置和进一步的链接优化，请参见上面的 URL。）
例如，在 macOS 上，可以使用
LTO=-flto=thin LTO_FC= LTO_LD=-Wl,-mllvm,-threads=4
使用 4 个线程对 C/C++ 代码使用瘦 LTO，但跳过使用 gfortran 编译的 Fortran 代码的 LTO。
据说在 LTO 情况下，对 clang 使用 -O3 特别有利。
似乎 flang 可能支持 LTO，但目前还没有文档。
英特尔的 C/C++ 编译器 2020 年代版本基于 LLVM，因此支持 LLVM 风格的 LTO，包括“完整”和“瘦”。这可能使用类似以下内容：
LTO=-flto=thin -flto-jobs=8
LTO 有效地将包中的所有源代码编译为一个单独的编译单元，因此允许编译器（使用足够的诊断标志，例如 -Wall）检查通常是单独编译单元之间的一致性。
使用 gcc/gfortran 9.x 及更高版本20，LTO 将标记对 Fortran 子例程/函数的调用中的不一致，包括 Fortran 源文件之间以及 Fortran 和 C/C++ 之间。 gfortran 8.4、9.2 及更高版本可以通过使用选项 -fc-prototypes-external 从 Fortran 源文件提取 C 原型来帮助理解这些不一致，例如（在撰写本文时）Fortran LOGICAL 对应于 C 中的 int_least32_t *。
只有在安装测试文件后才能进行完整的安装后测试。
make install-tests
它会在安装过程中填充一个名为 tests 的目录。
如果已完成此操作，则可以使用两种测试方法。第一种方法是移动到 R 安装的主目录（由 R RHOME 或在 R 中作为 R.home() 给出）并运行
cd tests ## followed by one of ../bin/R CMD make check ../bin/R CMD make check-devel ../bin/R CMD make check-all
其他有用的目标是 test-BasePackages 和 test-Recommended，分别用于运行标准和推荐包（如果已安装）的测试。
这将重新运行与已安装的 R 相关的所有测试（例如，包括包小插图中的代码），但不包括检查手册中的示例代码或制作独立的 Rmath 库的测试。当操作系统环境发生变化时，这偶尔会很有用，例如通过操作系统更新或通过替换 BLAS（参见 共享 BLAS）。
可能可以并行检查包：将环境变量 TEST_MC_CORES 设置为要并行运行的最大进程数。这会影响检查包示例（make check 的一部分）和包源代码（make check-devel 和 make check-recommended 的一部分）。它确实需要一个支持 make -j n 选项的 make 命令：大多数都支持。
或者，可以运行已安装的 R，最好使用 --vanilla。然后
pdf("tests.pdf") ## optional, but prevents flashing graphics windows
Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
tools::testInstalledBasic("both")
tools::testInstalledPackages(scope = "base")
tools::testInstalledPackages(scope = "recommended")
运行基本测试，然后运行标准和推荐包上的所有测试。这些测试可以在任何地方运行：基本测试将其结果写入 R 主目录的 tests 文件夹中，并且运行的测试比第一种方法少：特别是它们不测试需要互联网访问的东西——可以通过以下方式测试
tools::testInstalledBasic("internet")
即使没有运行 make install-tests，也可以通过 testInstalledPackages 测试已安装的包（但不能测试其包特定的测试）。除非 outDir 指定了不同的目录，否则输出将写入当前目录下。
请注意，结果可能取决于为时间和消息设置的语言：为了最大程度地与参考结果相似，您可能需要尝试设置（在启动 R 会话之前）
LANGUAGE=en
并使用 UTF-8 或 Latin-1 本地化。
[本段落其余内容仅在发布后才相关。] bin/windows 目录包含来自 CRAN 的基础发行版和大量附加包的二进制文件，可在 64 位 Windows 上运行。
R 最好在 Windows 10 和 Windows Server 2022 的当前版本上进行测试，字符集编码为 UTF-8。它也适用于 Windows 11。它可以在旧版本的 Windows 上运行，但通常使用其他字符集编码，可能需要手动安装通用 C 运行时 (UCRT)。
您的文件系统必须允许长文件名（除了可能的一些网络挂载系统）。如果它不支持转换为短名称等效项（也称为 DOS 8.3 名称），则 R 必须安装在不包含空格的路径中。
安装是 通过安装程序 R-4.3.3-win.exe 进行的。只需双击图标并按照说明操作。您可以从控制面板卸载 R。
系统会要求您选择安装语言：该选择适用于安装和卸载，但不适用于运行 R 本身。
有关二进制安装程序的更多详细信息以及在旧版 Windows 系统上使用 R 的信息，请参阅 R Windows FAQ。
可以使用其他 64 位工具链（包括“MSYS2”）以及 UCRT 支持来构建 R，但本手册仅记录用于 R 4.2.x 及更高版本的二进制发行版的工具链。使用其他工具链时，可能需要调整 R 和包的 Makefile。
R 的二进制发行版目前使用来自 Windows 的 Rtools43 的工具构建。有关如何使用它的更多详细信息，请参阅 构建 R 和包。
该工具集包括来自 “MinGW-w64”项目 的编译器（GCC 版本 12.2.0 以及选定的其他补丁）和运行时库，以及由 R 和 R 包使用的许多预编译静态库和头文件，由 “MXE”（M 交叉环境，由 Tomas Kalibera 维护更新）编译。该工具集还包括来自 “MSYS2”项目 的构建工具。可以通过包管理器（“pacman”）安装由“MSYS2”打包的额外构建工具。
从 2008 年到 2022 年，用于 64 位 Windows 的工具集基于 MinGW-w64。感谢 Yu Gong 在将 R 移植到 MinGW-w64 的关键步骤中提供的帮助，以及 MinGW-w64 项目的首席开发者 Kai Tietz 和 Martin Storsjo 的帮助。
构建 R 和检查包都需要安装 LaTeX 发行版，并且包含 pdflatex 的目录在路径中。
LaTeX 的 ‘MiKTeX’ (https://miktex.org/) 发行版是 CRAN 上使用的发行版。它可以设置为 ‘即时’ 安装额外的包（无需询问），这是使用它的最简单方法。‘MiKTeX’ 的 ‘基本’ 版本需要添加一些包。21 在任何情况下，请确保安装了 inconsolata 包——您可以使用 ‘MiKTeX’ 包管理器进行检查。
也可以使用来自 https://www.tug.org/texlive/ 的 TeX Live 发行版。（CRAN 包 tinytex 可以安装和管理 TeX Live 的子集。）
您可以通过运行以下命令来测试构建
make check
推荐的包可以通过以下命令进行检查
make check-recommended
其他级别的检查是
make check-devel
用于更彻底地检查 R 功能，以及
make check-all
用于 check-devel 和 check-recommended。
如果测试失败，几乎总是会在被检查的目录中有一个 .Rout.fail 文件（通常是 tests/Examples 或 tests）：检查该文件以帮助查明问题。
包源代码的并行检查（make check-devel 和 make check-recommended 的一部分）是可能的：请参阅环境变量 TEST_MC_CORES 以了解要并行运行的最大进程数。
Windows 安装程序包含一组在构建 R 时使用的测试文件。
运行这些测试不需要工具集，但如果 diff 在路径中，将提供更全面的错误分析。
启动 Rgui 或 Rterm（推荐），最好使用 --vanilla 选项。然后运行
Sys.setenv(LC_COLLATE = "C", LC_TIME="C", LANGUAGE = "en")
tools::testInstalledBasic("both")
tools::testInstalledPackages(scope = "base")
tools::testInstalledPackages(scope = "recommended")
运行基本测试，然后运行标准和推荐包的所有测试。这些测试可以在任何地方运行：testInstalledBasic 将结果写入 R 主目录（由 R.home() 给出）的 tests 文件夹，而 testInstalledPackages 则写入当前目录，除非 outDir 指定了其他目录。
为了使 tests 文件夹可写，通常需要将 R 安装到默认目录 C:\Program Files 以外的目录。安装程序还允许在没有管理员权限的情况下安装 R，有关更多详细信息，请参阅 R Windows FAQ。
测试 tools 时，example(md5sums) 的结果可能与参考输出不同，因为某些文件是使用 Windows 的 CRLF 行结束符安装的。此外，reg-plot-latin1.pdf 中也可能存在差异。
您也可以从工具集 shell（例如 bash）中运行测试，类似于类 Unix 安装。移动到 R 安装的主目录（由 R RHOME 给出，或从 R 中使用 R.home() 给出），然后运行
cd tests ## followed by one of ../bin/R CMD make check ../bin/R CMD make check-devel ../bin/R CMD make check-all
请记住，LaTeX 需要在路径中。
[本段其余内容仅在发布后才相关。] CRAN 网站首页有一个链接“下载适用于 (Mac) OS X 的 R”，它会将您带到一个新页面。提供两个文件供下载，R-4.3.3-arm64.pkg 和 R-4.3.3.pkg。两者都适用于 macOS 11 或更高版本（Big Sur、Monterey、Ventura 等）。
第一个运行适用于“Apple Silicon”（也称为“M1”、“M2”或“M3”）Mac，第二个适用于使用“x86_64”（Intel）CPU 的旧款 Mac。
包 R-4.3.3.pkg 也可以使用“Rosetta”模拟22 安装在“Apple Silicon”CPU 上，但原生构建更可取。它速度稍快（对于某些任务来说快得多），但可能会给出与更常见的“x86_64”平台（在 Windows、Linux 等以及 macOS 上）不同的数值结果，因为 ARM 硬件缺乏扩展精度浮点运算。
重要的是，如果您使用二进制安装程序包，请确保您的操作系统已完全更新：查看“系统偏好设置”中的“软件更新”以确保。
要安装，只需双击您下载的文件的图标。在“安装类型”阶段，请注意“自定义”选项。目前显示了四个组件：每个人都需要“R 框架”组件：其余组件是可选的。（“Tcl/Tk”组件是使用包 tcltk 所必需的。“Texinfo”组件仅供安装源包或从源代码安装 R 的用户使用。）
注意 Ventura 用户：从 Downloads 文件夹安装可能不被允许，或者可能需要额外的授权，因此我们建议您下载到其他地方，例如您的桌面或主文件夹。
这些是 Apple 安装程序包。如果您在安装过程中遇到任何问题，请通过单击“窗口”菜单和“安装程序日志”项检查安装程序日志。完整的输出（选择“显示所有日志”）对于追踪问题很有用。请注意，安装程序足够智能，可以尝试升级您安装应用程序的最后一个已安装版本（这可能不是您这次想要的位置……）。
构建的各个部分需要安装 XQuartz：请参阅 https://www.xquartz.org/releases/.23 这些包括 tcltk 包和 X11 图形设备：尝试在没有 XQuartz 的情况下使用它们会提醒您。这对于某些基于 cairographics 的设备（在 macOS 上并不常用）的 构建也是必需的，例如 png(type = "cairo") 和 svg() 以及一些第三方软件包（例如 rgl）。
如果您更新了 macOS 版本，您应该重新安装 R（也许还有 XQuartz）：安装程序可能会根据当前的 OS 版本调整安装。
R-patched 和 R-devel 的安装程序通常可以从 https://mac.R-project.org 获取。（其中一些软件包可能未签名/未经公证：要安装这些软件包，请按 Control/右键/双指点击，选择“打开方式”和“安装程序”。）
有关从源代码构建 R，请参阅 macOS。
有两种方法可以在 macOS 上从 CRAN 二进制发行版运行 R。
有一个 GUI 控制台通常与 /Applications 中的 R 图标一起安装，您可以通过双击运行（例如，从 Launchpad 或 Finder）。（如果您在那里找不到它，它可能安装在其他地方，因此请尝试在 Spotlight 中搜索它。）这通常被称为 R.APP 以将其与命令行 R 区分开：其用户手册目前是 macOS FAQ 的一部分，位于 https://cran.r-project.org.cn/bin/macosx/RMacOSX-FAQ.html，并且可以从 R.APP 的“帮助”菜单中查看。
您可以在终端24中运行命令行 R 和 Rscript，因此可以像在任何其他类 Unix 系统上一样将它们键入为命令：请参阅本手册的下一章。在其他平台上使用 R 的用户可能会发现一些细微的差异，最值得注意的是个人库目录的默认位置（在 ~/Library/R 下，例如 ~/Library/R/x86_64/4.2/library），以及警告、消息和其他输出到 stderr 会以粗体突出显示。
使用 zsh shell（从 Catalina 开始，这是新用户帐户的默认 shell）的用户可能会发现命令 R 被 zsh 内置命令 r（用于调用命令）屏蔽。可以在别名中使用 R 的完整路径，或者将 disable r 添加到 ~/.zshrc。
如果您在 arm64 Mac 上安装了两个安装程序包，则将使用最后安装的安装程序包。
据报道，如果未存储任何首选项，则运行 R.APP 可能会失败，因此如果在首次启动时失败，请尝试再次运行（第一次尝试将存储一些首选项）。
使用 R.APP 的用户需要注意“App Nap”功能 (https://developer.apple.com/library/archive/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html)，该功能会导致 R 任务在控制台中未产生输出时运行速度非常慢。以下是一些避免此问题的方法
defaults write org.R-project.R NSAppSleepDisabled -bool YES
使用 X11 图形设备或 View() 和 edit() 的基于 X11 的版本（用于数据帧和矩阵，后者是命令行 R 的默认值，但不是 R.APP）需要安装 XQuartz。
在某些相当模糊的情况下，在使用基于 cairo 的设备（尤其是 X11(type = "cairo")）时，已看到来自 fontconfig 的有关缺少/不可读配置文件的消息。安装 XQuartz 后，将有两个来自不同版本的 fontconfig 区域，并且设置以下内容可能会有所帮助
setenv FONTCONFIG_PATH /opt/X11/lib/X11/fontconfig
另一个症状是斜体/倾斜字体被替换为直立字体。
macOS 版 R 包含两个部分：GUI (R.APP) 和 R 框架。卸载就像删除这些文件夹一样简单（例如，将它们拖放到 Bin 或垃圾箱中）。典型的安装会将 GUI 安装到 /Applications/R.app 文件夹中，并将 R 框架安装到 /Library/Frameworks/R.framework 文件夹中。指向 R 和 Rscript 的链接也应该从 /usr/local/bin 中删除。
如果您想使用终端更彻底地摆脱 R，只需运行
sudo rm -Rf /Library/Frameworks/R.framework /Applications/R.app \ /usr/local/bin/R /usr/local/bin/Rscript
安装包括最多四个 Apple 包：25 针对 Intel 版本，org.R-project.x86_64.R.fw.pkg、org.R-project.x86_64.R.GUI.pkg、org.r-project.x86_64.tcltk 和 org.r-project.x86_64.texinfo。您可以使用 sudo pkgutil --forget，如果您希望 Apple 安装程序忘记该包而不删除其文件（在并行安装多个 R 版本时，这对 R 框架很有用），或者在您删除文件后。 注意：包名称区分大小写，R 域的命名不一致。
卸载 Tcl/Tk 和 Texinfo 组件（安装在 /opt/R/x86_64 下，在“x86_64”版本上，以及 /opt/R/arm64 下，在“arm64”版本上）并不那么简单。您可以在终端中列出它们安装的文件，例如
pkgutil --files org.r-project.x86_64.tcltk pkgutil --files org.r-project.x86_64.texinfo
（对于“Apple Silicon”版本，将 x86_64 替换为 arm64。）这些是相对于 / 的路径，即文件系统的根目录。
如果您没有编译 R 或者从源代码安装包，您可以删除所有 /opt/R/x86_64 或 /opt/R/arm64 文件夹。
如何在 R 简介 中的 启动 R 以及可用的命令行选项将在 启动 R 中讨论。
您应该确保 shell 设置了足够的资源限制：R 预计堆栈大小至少为 8MB，并且能够打开至少 256 个文件描述符。（任何现代操作系统都应该具有至少与这些限制一样大的默认限制，但显然 NetBSD 可能没有。使用 shell 命令 ulimit (sh/bash) 或 limit (csh/tcsh) 来检查。）对于某些编译器27 和包，需要更大的堆栈大小：迄今为止，20-25MB 已足够。
R 使用了许多环境变量，其中许多的默认值在文件 R_HOME/etc/Renviron 中设置（在 Windows 上默认情况下没有设置任何环境变量，因此没有这样的文件）。这些变量在 configure 阶段设置，您通常不会想要更改它们——一个可能的例外是 R_PAPERSIZE（参见 设置纸张大小）。如果存在“LC_PAPER”区域设置类别并且 R_PAPERSIZE 未设置，则纸张大小将从该类别中推断出来，这通常会在现代类 Unix 系统上产生正确的选择（例如“a4”和“letter”，但始终可以通过设置 R_PAPERSIZE 来覆盖）。
可以通过设置各种环境变量来确定 R 在每个会话中创建临时目录的位置。环境变量 TMPDIR、TMP 和 TEMP 会依次被搜索，第一个被设置且指向可写区域的变量会被使用。如果都没有设置，最终的默认值是类 Unix 系统上的 /tmp，以及 Windows 上 R_USER 的值。该路径应该是绝对路径，不包含空格28（最好避免使用非字母数字字符，例如 + 或引号）。
一些类 Unix 系统被设置为定期从 /tmp 中删除文件和目录，例如通过运行 tmpwatch 的 cron 作业 。在这样的系统上启动长时间运行的作业之前，请将 TMPDIR 设置为另一个目录。
请注意，TMPDIR 将用于在安装包时执行 configure 脚本，因此如果 /tmp 被挂载为 ‘noexec’，则需要将 TMPDIR 设置为允许执行的目录。
使用正确的术语很有帮助。一个 包 由函数 library() 从一个 库 中加载。因此，库是一个包含已安装包的目录；主库是 R_HOME/library，但也可以使用其他库，例如通过 设置环境变量 R_LIBS 或使用 R 函数 .libPaths()。为了避免任何混淆，您经常会看到库目录被称为 ‘库树’。
启动时加载的包集默认情况下为
> getOption("defaultPackages")
[1] "datasets" "utils" "grDevices" "graphics" "stats" "methods"
(当然，还有 base)，可以通过在启动代码中设置选项来更改（例如，在 ~/.Rprofile 中）。它最初 设置为环境变量 R_DEFAULT_PACKAGES 的值（如果设置，以逗号分隔的列表形式）。设置 R_DEFAULT_PACKAGES=NULL 确保仅加载 base 包。
更改默认包集通常用于在脚本编写时减少包集以提高速度：特别是，不使用 methods 会将启动时间减少至多两倍。但它也可以用于自定义 R，例如用于课堂使用。 Rscript 也检查环境变量 R_SCRIPT_DEFAULT_PACKAGES； 如果设置，它将优先于 R_DEFAULT_PACKAGES。
R 包安装到 库中，库是文件系统中的目录，包含每个安装在其中的包的子目录。
R 带有一个库，R_HOME/library，它是 R 对象 ‘.Library’ 的值，包含标准和推荐的29 包。站点和用户都可以创建其他库并使用它们（或不使用它们）在 R 会话中。在最低级别，可以使用 ‘.libPaths()’ 将路径添加到库集合中，或报告当前集合。
如果存在特定于站点的库 R_HOME/site-library（在 vanilla R 安装中不存在），R 会自动使用它。可以通过在 R_HOME/etc/Rprofile.site 中设置 30 ‘.Library.site’ 来覆盖此位置，或者（不推荐）通过设置环境变量 R_LIBS_SITE 来覆盖。
用户可以拥有一个或多个库，通常由环境变量 R_LIBS_USER 指定。它有一个默认值（要查看它，在 R 会话中使用 ‘Sys.getenv("R_LIBS_USER")’），但只有在相应的目录实际存在时才会使用（默认情况下不会存在）。
R_LIBS_USER 和 R_LIBS_SITE 都可以指定多个库路径，用冒号（在 Windows 上用分号）分隔。
包可以以源代码形式或编译后的二进制形式分发。安装包含 C/C++/Fortran 代码的源代码包需要安装编译器和相关工具。二进制包是特定于平台的，通常不需要任何特殊工具来安装，但有关详细信息，请参阅您平台的文档。
请注意，您可能需要隐式或显式地指定要安装包的库。当然，只有当您有多个库时，这才是问题。
确保环境变量 TMPDIR 未设置（并且 /tmp 存在并且可以写入和从其中执行）或它是有效临时目录的绝对路径，不包含空格。
对于大多数用户来说，如果要安装 CRAN 包并且可以访问互联网，只需调用 ‘install.packages(pkgname)’ 或其 GUI 等效项即可。 31 在大多数系统上，‘install.packages()’ 允许从列表框中选择包（通常有数千个项目）。
要在类 Unix 系统上从源代码安装包，请在终端中使用
R CMD INSTALL -l /path/to/library pkg1 pkg2 ...
部分 ‘-l /path/to/library’ 可以省略，在这种情况下，将使用普通 R 会话的第一个库（由 .libPaths()[1] 显示）。
有多种选项可用：使用 R CMD INSTALL --help 查看当前列表。
或者，可以在 R 中下载和安装包。首先使用 chooseCRANmirror() 选择您最近的 CRAN 镜像。然后下载并安装包 pkg1 和 pkg2，方法如下：
> install.packages(c("pkg1", "pkg2"))
指定包的基本依赖项也将被获取。除非指定库（参数 lib），否则将使用库搜索路径中的第一个库：如果该库不可写，R 将询问用户（在交互式会话中）是否应创建默认个人库，如果允许，则将在该库中安装包。
如果您想获取一个包及其所有依赖项（以任何方式），这些依赖项尚未安装，请使用例如：
> install.packages("Rcmdr", dependencies = TRUE)
install.packages 可以从本地 .tar.gz 文件（或指向该文件的 URL）安装源包，方法是将参数 repos 设置为 NULL：如果给定的名称是单个 .tar.gz 文件，则会自动选择此方法。
install.packages 可以查看多个存储库，这些存储库由参数 repos 指定为字符向量：这些存储库可以包括 CRAN 镜像、Bioconductor、R-forge、rforge.net、本地存档、本地文件等。函数 setRepositories() 可以从 R 安装程序知道的这些存储库中进行选择。
有时让用户困惑的是，install.packages() 可能会报告他们认为应该可用的包未找到。一些可能的原因
getOption("repos")
pkg 的可用版本的相关信息，请使用：
av <- available.packages(filters=list()) av[av[, "Package"] == pkg, ]
在您的 R 会话中，查看 ‘Depends’ 和 ‘OS_type’ 字段（可能存在多个匹配项）。如果该包依赖于比正在使用的版本更新的 R 版本，则可能存在较早的版本，该版本可以与您的 R 版本一起使用：对于 CRAN，请在该包的 CRAN 着陆页上查找“旧源”，并手动检索适当的版本（与您的 R 版本年龄相当）。
新手用户有时会忘记，除了安装包之外，他们还需要使用 library 来使包的功能可用。
install.packages 在 Unix 类系统（macOS 除外）和 Windows 上的默认行为有所不同。在 Unix 类系统上，它会查询 CRAN（或其他存储库）上的可用 源代码 包列表，下载最新版本的包源代码，并安装它们（通过 R CMD INSTALL）。在 Windows 上，它（默认情况下）首先查看适用于您的 R 版本的可用 二进制 包列表，并下载最新版本（如果有）。如果没有可用的二进制版本或源代码版本更新，它将安装没有编译 C/C++/Fortran 代码的包的源代码版本，并提供安装包含编译代码的包的选项，前提是 make 可用（这可以通过选项 "install.packages.compile.from.source" 进行调整）。
在 Windows 上，install.packages 还可以通过将参数 repos 设置为 NULL 来安装来自本地 zip 文件（或此类文件的 URL）的二进制包。 Rgui.exe 具有一个 Packages 菜单，其中包含用于 install.packages、update.packages 和 library 的 GUI 接口。
用于 R 的 Windows 二进制包以单个二进制文件形式分发，该文件包含一个或两个体系结构（32 位和 64 位）。从 R 4.2.0 开始，它们始终只包含 64 位体系结构。
R CMD INSTALL 在 Windows 上工作以安装源代码包。如果包不包含编译代码，则不需要额外的工具，并且 install.packages(type="source") 将适用于此类包。包含编译代码的包需要工具（参见 Windows 工具集）。当由工具集安装程序安装时，R 会自动找到这些工具。有关更多详细信息，请参见 构建 R 和包。
在某些系统上，解包源代码包后偶尔会出现权限问题：可以通过将环境变量 R_INSTALL_TAR 设置为 ‘tar.exe’ 来解决这些问题。
如果您只有一个已知与当前 R 版本兼容的源代码包，并且只想获得它的 Windows 二进制版本，您可以使用 https://win-builder.r-project.org/ 提供的构建服务。
对于几乎所有包，R CMD INSTALL 将尝试安装 32 位和 64 位版本的包，前提是它是在 32/64 位版本的 R 中运行的（从 R 4.2.0 开始，只支持 64 位版本和安装）。如果运行的 R 架构的安装成功，它将报告成功，无论其他架构是否成功安装。例外情况是包含非空 configure.win 脚本或使用 src/Makefile.win 的包。如果 configure.win 对两种架构都执行了适当的操作，请使用32 选项 --force-biarch：否则，可以使用 R CMD INSTALL --merge-multiarch 将单独的 32 位和 64 位安装合并到源代码包中。（这只能应用于 tarball，并且只有在两种安装都成功的情况下才会成功。）
如果您有一个没有编译代码且没有 Windows 特定帮助的包，您可以将另一个操作系统上的安装压缩成 zip 文件，然后在 Windows 上从该 zip 文件安装。但是，这样的包可以在 Windows 上从源代码安装，而无需任何额外的工具。
在 macOS 上，install.packages 的工作方式与其他类 Unix 系统相同，但它还提供了一种额外的类型 mac.binary（可用于 CRAN 发行版，但不能用于从源代码编译 R），它可以传递给 install.packages 以从合适的存储库下载和安装二进制包。这些用于 macOS 的二进制包文件扩展名为 ‘.tgz’。 R.APP GUI 提供了菜单，用于从 CRAN、其他存储库或本地文件安装二进制包或源代码包。
在使用二进制包的 R 构建中，默认类型为 both：这首先查看适用于您的 R 版本的二进制包列表，并安装最新版本（如果有）。如果找不到二进制版本或源版本更新，它将安装不包含已编译 C/C++/Fortran 代码的包的源版本，并在 make 可用时，提供安装包含已编译代码的包的选项。
请注意，大多数包含已编译代码的二进制包都与特定系列的 R（例如 R 4.2.x 或 4.3.x）绑定。
安装不包含已编译代码的源包应该无需任何额外工具。对于其他包，您将需要 Xcode 的“命令行工具”和与用于构建 R 的编译器匹配的编译器，以及用于包含 Fortran 代码的包的 Fortran 编译器：请参阅 macOS。
包 rJava 及其依赖项需要安装 Java 运行时，并且一些包需要安装 X11，包括使用 Tk 的包。请参阅 macOS 和 Java。包 rjags 需要在 /usr/local 下安装 JAGS 构建，例如 https://sourceforge.net/projects/mcmc-jags/files/JAGS/4.x/Mac%20OS%20X/ 上的构建。
Tcl/Tk 扩展 BWidget 以前与 R 一起分发，但现在不再分发；Tktable 已与大多数版本的 R 一起分发（但 4.0.0 和 4.1.0 或 4.1.1 的“arm64”构建除外）。
指定的默认编译器显示在文件 /Library/Frameworks/R.framework/Resources/etc/Makeconf 中。在编写本文档时，这些设置假设 C、Fortran 和 C++ 编译器位于路径中（参见 macOS）。这些设置可以通过编辑该文件或在诸如 ~/.R/Makevars 的文件中进行更改（参见下一节）。可能需要更改的条目包括 ‘CC’、‘CXX’、‘FC’、‘FLIBS’ 以及相应的标志，以及可能需要更改的条目包括 ‘CXXCPP’、‘DYLIB_LD’、‘MAIN_LD’、‘SHLIB_CXXLD’ 和 ‘SHLIB_LD’，以及它们的 ‘CXX11’、‘CXX14’、‘CXX17’ 和 ‘CXX20’ 变体。
例如，您可以选择一个特定的 LLVM clang 用于 C 和 C++，并进行广泛的检查，方法是在 ~/.R/Makevars 中添加以下内容
CC = /usr/local/clang/bin/clang -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk CXX = /usr/local/clang/bin/clang++ -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk CXX11 = $CXX CXX14 = $CXX CXX17 = $CXX CXX20 = $CXX CFLAGS = -g -O2 -Wall -pedantic -Wconversion -Wno-sign-conversion CXXFLAGS = -g -O2 -Wall -pedantic -Wconversion -Wno-sign-conversion CXX11FLAGS = $CXXFLAGS CXX14FLAGS = $CXXFLAGS CXX17FLAGS = $CXXFLAGS CXX20FLAGS = $CXXFLAGS
(长行仅在手册中拆分) 以及当前 macOS 分发版中的 gfortran，位于 https://mac.r-project.org/tools/
FC = /opt/gfortran/bin/gfortran (arm64) FLIBS = -L/opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/12.2.0 -L/opt/gfortran/lib -lgfortran -lemutls_w -lquadmath (Intel) FLIBS = -L/opt/gfortran/lib/gcc/x86_64-apple-darwin20.0/12.2.0 -L/opt/gfortran/lib -lgfortran -lquadmath
(行在此处仅在手册中拆分)。
如果该 clang 构建支持 OpenMP，您可以添加
SHLIB_OPENMP_CFLAGS = -fopenmp SHLIB_OPENMP_CXXFLAGS = -fopenmp
以编译使用 OpenMP 的包。还需要确保 libomp.dylib 库在安装时和运行时都能找到，例如，将其复制/链接到搜索路径中的某个位置，例如 /usr/local/lib。
Apple 在 macOS 中包含许多开源库，但越来越多的库没有相应的头文件（甚至在 Xcode 或命令行工具中都没有）：它们通常是相当旧的版本。如果从源代码安装使用这些库的包，通常最简单的方法是从其源代码或从 https://mac.r-project.org/bin/ 安装一个静态链接的最新版本的开源包。但有时需要/希望使用 Apple 的动态链接库，在这种情况下，可以从 https://opensource.apple.com 获取的源代码33 中提取适当的头文件——这已用于 iodbc。
使用命令行工具/Xcode 12 或更高版本（适用于 macOS 11 ‘Big Sur’）的用户可能希望将标志
-Wno-implicit-function-declaration
作为 CFLAGS 的一部分。苹果已将默认值更改为使隐式声明成为编译错误，而软件包和外部软件的作者没有意识到这一点——大多数问题出现在 configure 脚本中。
在为软件包安装外部软件时，可能需要谨慎选择编译器。用于构建 R 的“系统”编译器是 clang 和 clang++，但 Apple 工具链还提供名为 gcc 和 g++ 的编译器，尽管它们的名字，但它们基于 LLVM 和 libc++，就像系统编译器一样，并且行为几乎与系统编译器相同。大多数开源软件都有一个使用 GNU autoconf 开发的 configure 脚本，因此它将选择 gcc 和 g++ 作为默认编译器：这通常可以正常工作。为了保持一致性，可以使用
./configure CC=clang CFLAGS=-O2 CXX=clang++ CXXFLAGS=-O2
（避免 autoconf 的默认 -g）。如果您将 /usr/local/gfortran/bin 目录放在您的路径上，请小心，因为该目录可能包含（真正的）gcc 和 g++，这些命令可能会被找到，而不是 Apple 提供的命令，并且可能无法找到 SDK 的头文件和库34。从 R 4.3.0 开始，R CMD INSTALL 和 install.packages() 尝试使用与构建 R 相同的编译器和标志调用 configure。
对于“arm64”，并非所有配置脚本都已更新以识别平台，因此可能需要标志 --build=aarch64-apple-darwin20.1.0。此外，请注意，从“x86_64”应用程序运行编译器会将它们切换为为该 CPU 生成代码：这适用于终端、shell、旧的 cmake 或（非系统）make，以及从 R CMD INSTALL 或 install.packages()。可以使用
./configure CC="clang -arch arm64" CFLAGS=-O2 CXX="clang++ -arch arm64" CXXFLAGS=-O2
强制“arm64”代码。
可以通过在个人文件 HOME/.R/Makevars-R_PLATFORM （但在 Windows 上为 HOME/.R/Makevars.win 或 HOME/.R/Makevars.win64）中设置适当的 Make 变量来覆盖或添加 R 系统和特定于包的编译标志，或者如果该文件不存在，则在 HOME/.R/Makevars 中设置，其中 ‘R_PLATFORM’ 是 R 构建的平台，可在 R 变量 R.version 的 platform 组件中获得。可以通过环境变量 R_MAKEVARS_USER 指定备用个人文件的完整路径35。
鼓励包开发者使用此机制在编译时启用适量的诊断消息（“警告”），例如 GCC（GNU 编译器集合）工具的 -Wall -pedantic，或 clang。
请注意，当需要在安装特定包时更改优化级别时，也可以使用此机制。例如
## for C code CFLAGS = -g -O -mtune=native ## for C++ code CXXFLAGS = -g -O -mtune=native ## for C++11 code CXX11FLAGS = -g -O -mtune=native ## for fixed-form Fortran code FFLAGS = -g -O -mtune=native ## for C17 code C17FLAGS = -g -O -mtune=native -Wno-strict-prototypes
请注意，如果您指定了非默认的 C++ 或 C 标准，则需要设置适合该标准的标志。
另一个用途是覆盖 R 二进制安装中的设置。例如，对于 https://mac.r-project.org/tools/ 上的当前 gfortran 分发版
FC = /opt/gfortran/bin/gfortran (arm64) FLIBS = -L/opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/12.2.0 -L/opt/gfortran/lib -lgfortran -lemutls_w -lquadmath (Intel) FLIBS = -L/opt/gfortran/lib/gcc/x86_64-apple-darwin20.0/12.2.0 -L/opt/gfortran/lib -lgfortran -lquadmath
(行在此处仅在手册中拆分)。
还为 R_HOME/etc 下的站点范围 Makevars.site 文件提供了支持（如果适用，则在特定于子架构的目录中）。此文件在 Makeconf 之后立即读取，并且可以通过环境变量 R_MAKEVARS_SITE 指定备用文件的路径。
请注意，这些机制不适用于无法将设置传递给子 make 的包，这些包可能在子目录中的 makefile 中读取 etc/Makeconf。幸运的是，此类包并不常见。
从源代码安装包时，对于使用子体系结构的安装，有一些额外的注意事项。这些通常在 Windows 上使用，但原则上可以在其他平台上使用。
当一个源代码包被支持多个子体系结构的 R 版本安装时，正常的安装过程会为所有子体系结构安装包。例外情况是
存在 configure 脚本或文件 src/Makefile。
存在非空的 configure.win 脚本或文件 src/Makefile.win（有一些例外情况，例如已知包具有与体系结构无关的 configure.win，或者使用 --force-biarch 选项或 DESCRIPTION 文件中的 ‘Biarch’ 字段来断言这一点）。
在这些情况下，只安装当前体系结构。可以通过以下方式安装其他子体系结构：
R CMD INSTALL --libs-only pkg
使用 R 或 R --arch 的路径来选择额外的子体系结构。还可以使用 R CMD INSTALL --merge-multiarch 来构建和合并两个体系结构，从源代码压缩包开始。
一些 R 包包含已编译的代码，这些代码链接到外部软件库。除非外部库是静态链接的（这在 Windows 和 macOS 上的二进制包中尽可能地完成），否则这些库必须在包加载时找到，而不仅仅是在安装时找到。如何做到这一点取决于操作系统（在某些情况下还取决于版本）。
对于除 macOS 之外的类 Unix 系统，主要机制是 ld.so 缓存，由 ldconfig 控制：记录在该缓存中的外部动态库将被找到。标准库位置将被缓存覆盖，设计良好的软件会添加其位置（例如，openmpi 在 Fedora 上就是这样做的）。次要机制是查询环境变量 LD_LIBRARY_PATH。R 脚本控制该变量，并将其设置为 R_LD_LIBRARY_PATH、R_JAVA_LD_LIBRARY_PATH 和 LD_LIBRARY_PATH 的环境值的串联。前两个具有默认值，这些默认值通常在安装 R 时设置（但可以在环境中覆盖），因此 LD_LIBRARY_PATH 是用户设置的最佳选择。
在 macOS 上，主要机制是将依赖动态库的绝对路径嵌入到编译时的对象中。很少有 R 包安排这样做，但可以通过 install_name_tool 编辑36 via — 这只处理直接依赖项，而这些依赖项也需要编译以包含其依赖项的绝对路径。如果要将绝对路径的选择推迟到加载时，则如何解析它们在 man dyld 中有描述：LD_LIBRARY_PATH 的作用在 macOS 上被 DYLD_LIBRARY_PATH 和 DYLD_FALLBACK_LIBRARY_PATH 替换。在包共享对象上运行 R CMD otool -L 将显示其依赖项在哪里（如果有的话）被解析。 DYLD_FALLBACK_LIBRARY_PATH 是首选（它是由 R 脚本操作的），但从 10.11（“El Capitan”）开始，出于安全原因，默认行为已更改为在调用 shell 脚本时丢弃这些环境变量（而 R 是一个 shell 脚本）。这使得设置环境中的 R_LD_LIBRARY_PATH 成为唯一可移植的选项，类似于
export R_LD_LIBRARY_PATH="`R RHOME`/lib:/opt/local/lib"
Windows 在哪里查找 DLL 的精确规则很复杂，并且取决于 Windows 的版本。但就目前而言，主要解决方案是将包含包链接到的 DLL（以及这些 DLL 链接到的任何 DLL）的目录放在 PATH 上。
使用任何涉及设置环境变量的方法的危险是无意中屏蔽系统库。对于 DYLD_FALLBACK_LIBRARY_PATH 和在 Windows 上将 追加到 PATH 来说，这种情况较少（因为它应该已经包含系统库路径）。
命令 update.packages() 是确保系统中所有包都更新的最简单方法。它会下载可用包及其当前版本的列表，将其与已安装的包进行比较，并提供获取和安装任何在存储库中具有更高版本的包。
命令 packageStatus() 提供了另一种保持包更新的界面，它返回一个包含所有已安装包和多个存储库中可用包的信息的对象。 print 和 summary 方法概述了已安装和可用的包， upgrade 方法提供获取和安装过时包的最新版本。
packageStatus() 返回的另一个有时有用的信息是包的状态，例如 "ok"、 "upgrade" 或 "unavailable"（在当前选定的存储库中）。例如
> inst <- packageStatus()$inst
> inst[inst$Status != "ok", c("Package", "Version", "Status")]
Package Version Status
Biobase Biobase 2.8.0 unavailable
RCurl RCurl 1.4-2 upgrade
Rgraphviz Rgraphviz 1.26.0 unavailable
rgdal rgdal 0.6-27 upgrade
可以通过多种方式移除包。从命令提示符中，可以通过以下方式移除包：
R CMD REMOVE -l /path/to/library pkg1 pkg2 ...
从正在运行的 R 进程中，可以通过以下方式移除包：
> remove.packages(c("pkg1", "pkg2"),
lib = file.path("path", "to", "library"))
最后，可以从库中直接删除包目录。
诸如 install.packages 之类的工具可以指向任何 CRAN 风格的存储库，R 用户可能希望设置自己的存储库。存储库的“基础”是一个 URL，例如 https://www.stats.ox.ac.uk/pub/RWin/：这必须是 download.packages 支持的 URL 方案（也包括 ‘https://’、‘ftp://’ 和 ‘file://’）。在该基础 URL 下，应该为以下一种或多种类型的包分发创建目录树
"source": 位于 src/contrib 目录下，包含 .tar.gz 文件。也可以使用其他压缩格式，例如 .tar.bz2 或 .tar.xz 文件。完整的代码库包含与任何二进制包相对应的源代码，并且在任何情况下，最好在 src/contrib 目录下创建一个可能为空的 PACKAGES 文件。
"win.binary": 位于 bin/windows/contrib/x.y 目录下，适用于 R 版本 x.y.z，包含用于 Windows 的 .zip 文件。
"mac.binary": 位于 bin/macosx/contrib/4.y 目录下，适用于 macOS 上的 CRAN 构建，适用于 R 版本 4.y.z，包含 .tgz 文件。
"mac.binary.el-capitan": 位于 bin/macosx/el-capitan/contrib/3.y 目录下，适用于 R 版本 3.y.z 的 CRAN 构建，包含 .tgz 文件。
每个终端目录还必须包含一个 PACKAGES 文件。它可以是包的 DESCRIPTION 文件的连接，用空行分隔，但只需要其中的几个字段。设置此类文件的最简单方法是使用 tools 包中的 write_PACKAGES 函数，其帮助文档解释了哪些字段是必需的。可选地，还可以有 PACKAGES.rds 和 PACKAGES.gz 文件，它们优先于 PACKAGES 文件下载。（如果您有一个配置错误的服务器，无法正确报告不存在的文件，您可能需要这些文件。）
要将您的代码库添加到 setRepositories() 提供的列表中，请查看该函数的帮助文件。
不完整的代码库最好通过 contriburl 参数指定，而不是设置为代码库。
代码库可以包含子目录，当 PACKAGES 文件中子目录中包的描述必须包含以下形式的行时
Path: path/to/subdirectory
——再次，write_PACKAGES 是设置此项的最简单方法。
在已安装的包上运行 R CMD check 很方便，尤其是在使用子架构的平台上。操作方法如下，源包位于目录 pkg（或 tarball 文件名）中
R CMD INSTALL -l libdir pkg > pkg.log 2>&1 R CMD check -l libdir --install=check:pkg.log pkg
在使用子架构的情况下，可以通过以下方式重复 R CMD check 命令来添加其他架构：
R --arch arch CMD check -l libdir --extra-arch --install=check:pkg.log pkg
其中 --extra-arch 仅选择依赖于已安装代码的检查，而不选择分析源代码的检查。（如果多个子架构失败仅仅是因为它们需要不同的设置，例如环境变量，则可能需要在 INSTALL 行中添加 --no-multiarch。）在类 Unix 系统上，运行的架构由 --arch 选择：这也可以在 Windows 上使用 R_HOME/bin/R.exe，但更常见的是选择所需架构的 Rcmd.exe 的路径。
因此，在 Windows 上，要从另一个平台上测试过的 tarball 中安装、检查和打包一个源包以供分发，可以使用以下命令：
.../bin/x64/Rcmd INSTALL -l libdir tarball --build > pkg.log 2>&1
国际化是指支持多种人类语言的过程，而 本地化是指适应特定国家和语言。
当前版本的 R 支持底层操作系统可以处理的所有字符集。这些字符集根据 当前的 locale 进行解释，这是一个足够复杂的主题，值得单独讨论。但请注意，R 没有内置对从右到左语言和双向输出的支持，而是依赖于操作系统服务。例如，包含英语数字和希伯来语字符的 UTF-8 字符向量如何打印取决于操作系统（可能也取决于区域设置）。
国际化的另一个方面是支持消息翻译。这在几乎所有版本的 R 中都已启用。
一个 语言环境 是对用户本地环境的描述，包括首选语言、字符编码、使用的货币及其约定等等。语言环境的各个方面可以通过 R 函数 Sys.getlocale 和 Sys.localeconv 访问。
语言环境命名系统是操作系统特定的。在方案方面有相当广泛的共识，但在其实现细节方面则不然。语言环境需要指定
@latin, @cyrillic 用于塞尔维亚语，@iqtelif）或语言方言（例如，@saaho，阿法尔语的一种方言，以及 @bokmal 和 @nynorsk，挪威语的方言，被一些操作系统视为独立的语言，no 和 nn）。
R 主要关注第一个（用于翻译）和第三个。请注意，字符集可以从语言推断出来，因为某些操作系统每个语言只提供一个字符集。
现代 Linux 使用 XPG37 区域设置规范，其格式为 ‘en_GB’、‘en_GB.UTF-8’、‘aa_ER.UTF-8@saaho’、‘de_AT.iso885915@euro’ ，组件按上述顺序排列。（有关更多详细信息，请参见 man locale 和 locale -a。）大多数类 Unix 系统使用类似的方案：一些系统（包括一些 Linux 发行版）使用 ‘.utf8’ 而不是 ‘.UTF-8’。
请注意，虽然 UTF-8 区域设置如今几乎普遍使用，但诸如 ‘en_GB’ 之类的区域设置使用 8 位编码以实现向后兼容。
Windows 也使用区域设置，但以一种不太简洁的方式指定。大多数用户只会通过下拉菜单遇到区域设置，但可以通过搜索 ‘Windows language country strings’ 来找到更多信息和列表。
它每种语言只提供一个编码。
使用 Windows 的区域设置名称时需要小心。例如，chinese 是繁体中文，而不是大多数汉语世界使用的简体中文。
macOS 以其独特的方式支持区域设置，但 R GUI 试图让用户更容易使用。有关用户如何设置区域设置的信息，请参见 https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/。与 Windows 一样，最终用户通常只会看到语言/区域列表。在终端中使用 R 的用户可能需要将区域设置设置为类似于 ‘en_GB.UTF-8’ 的内容，如果它默认设置为 ‘C’（有时在远程登录和批处理作业时会发生：注意 Terminal 是否设置 LANG 环境变量是一个（高级）首选项，但默认情况下会这样做）。
在内部，macOS 使用类似于 Linux 的形式：与其他类 Unix 系统的主要区别在于，如果未指定字符集，则假定为 UTF-8。
消息的首选语言默认情况下取自区域设置。这可以通过设置环境变量 LANGUAGE 然后38 通过环境变量 LC_ALL、LC_MESSAGES 和 LANG 来覆盖。 （最后三个通常用于设置区域设置，因此不需要，但第一个仅用于选择消息的语言。）代码尽力将区域设置映射到语言，但在某些系统（尤其是 Windows）上，环境变量 LC_ALL 所需的区域设置名称并不都对应于 XPG 语言名称，因此可能需要设置 LANGUAGE。 （一个例子是 Windows 上的 ‘LC_ALL=es’，它将区域设置设置为爱沙尼亚语，将语言设置为西班牙语。）
通常，在 R 运行后可以更改语言（非 Windows）通过 Sys.setlocale("LC_MESSAGES", "new_locale")，或通过设置环境变量，例如 LANGUAGE，前提是39 您要更改到的语言可以在当前字符集中输出。但这与操作系统有关，并且已知在操作系统升级后停止工作。请注意，翻译后的消息可能会被缓存，因此尝试更改已在另一种语言中输出的错误的语言可能不起作用。
消息被分成域，并且某些或所有域中的消息可能提供翻译。R 使用以下域。
R 用于来自 R 解释器的 C 级错误和警告消息。
R-pkg 用于每个包中的 R stop、warning 和 message 消息，包括 R-base 用于 base 包。
pkg 用于每个包中的 C 级消息。
RGui 用于 R for Windows GUI 前端的菜单等。
以这种方式划分消息使 R 可扩展：加载包时，它们的翻译目录也可以加载。
R 可以构建为不支持翻译，但默认情况下已启用。
R 级和 C 级域略有不同，例如在字符串在传递以进行翻译之前被规范化的方式。
根据当前指定的语言，尽可能具体地按域查找翻译，例如，对于奥地利用户，将优先使用奥地利（‘de_AT’）翻译目录，而不是通用德语（‘de’）翻译目录。但是，如果存在特定翻译目录但未包含翻译，则会参考不太具体的目录。例如，R 具有针对 ‘en_GB’ 的目录，这些目录将标准消息中的美国英语（例如，‘gray’）翻译成英语。40 另外两个例子：有针对 ‘es’ 的目录，这是西班牙语，如西班牙所写，这些目录默认情况下也会在西班牙语系的拉丁美洲国家使用，还有针对 ‘pt_BR’ 的目录，这些目录用于巴西地区，但不用于指定葡萄牙的地区。
通过动态重新编码来利用正确语言但错误字符集的翻译 。 LANGUAGE 变量（仅）可以是冒号分隔的列表，例如 ‘se:de’，以递减的优先级顺序提供一组语言。一个特殊的值是 ‘en@quot’，它可以在 UTF-8 本地化中使用，以使带有单引号对的美国错误消息翻译成 Unicode 双向引号。
如果找不到合适的翻译目录，或者任何合适的目录中都没有翻译特定消息，则使用 ‘英语’41。
有关如何准备和安装翻译目录，请参阅 https://developer.r-project.org/Translations30.html。
几乎所有当前的 CPU 都有 32 位和 64 位指令集。一些在这些 CPU 上运行的操作系统提供了构建 32 位或 64 位版本的 R 的选择（具体细节将在下面针对特定操作系统进行说明）。对于大多数用户来说，64 位版本是默认选项，并且越来越成为唯一支持的版本——例如，macOS 从 Catalina（2019 年发布）开始就只支持 64 位，而 R 从 R 4.2.0 开始只支持 64 位 Windows。
所有当前版本的 R 都使用 32 位整数（在构建过程中强制执行）和 ISO/IEC 6055942 双精度实数，因此计算精度相同43，并且数值大小的限制也相同。主要区别在于指针的大小。
64 位版本既有优点也有缺点。
R 根据需要为大型对象分配内存，并在垃圾回收时删除所有未使用的对象。当对象的大小成为地址限制的相当一部分时，地址空间碎片化就会成为问题，并且可能没有可用的空闲空间来满足请求的大小。这会导致更频繁的垃圾回收或无法分配大型对象。作为参考，对于 32 位版本，当对象大小超过地址空间大小的 10%（约 300Mb）或正在使用的对象总大小约为三分之一（约 1Gb）时，这个问题就会出现。
configure 会在可能的情况下选择合适的定义。64 位版本具有更大的限制。
因此，为了速度，您可能想要使用 32 位版本（尤其是在笔记本电脑上），但为了处理大型数据集（以及可能的大文件），则需要使用 64 位版本。您通常可以构建这两个版本并将它们安装在同一个位置：请参见 子架构。
即使在 R 的 64 位版本中，R 对象的大小也有限制（参见 help("Memory-limits")），其中一些限制源于使用 32 位整数（尤其是在 Fortran 代码中）。例如，数组的每个维度都限制为 2^{31} - 1。
支持 R 中的分布和特殊函数44 的例程在 C 头文件 Rmath.h 中声明。这些例程可以编译成一个独立的库，用于链接到其他应用程序。（请注意，当构建 R 时，它们不是一个单独的库，并且独立版本在几个方面有所不同。）
所需的 makefile 和其他源代码位于目录 src/nmath/standalone 中，因此以下说明假设该目录是当前工作目录（在 Unix 类系统上的构建目录树中，如果它与源代码分开）。
Rmath.h 包含 ‘R_VERSION_STRING’，它是一个包含当前 R 版本的字符串，例如 "4.3.2"。
可以通过特殊版本的宏和函数完全访问 R 对 NaN、Inf 和 -Inf 的处理
ISNAN, R_FINITE, R_log, R_pow and R_pow_di
以及（外部）常量 R_PosInf、R_NegInf 和 NA_REAL。
不支持 R 的缺失值概念，特别是对于 NA_INTEGER 以及对于双精度数 NA 和 NaN 之间的区别。
使用随机数例程需要稍微注意一下。您需要提供均匀随机数生成器
double unif_rand(void)
或者使用提供的随机数生成器（对于共享库或 DLL，您可能需要使用提供的随机数生成器，即 Marsaglia 多重进位随机数生成器，其入口点
set_seed(unsigned int, unsigned int)
用于设置其种子）。
可以通过常量 N01_kind 更改默认随机数生成器。该常量取自枚举类型
typedef enum {
BUGGY_KINDERMAN_RAMAGE,
AHRENS_DIETER,
BOX_MULLER,
USER_NORM,
INVERSION,
KINDERMAN_RAMAGE
} N01type;
（并且 ‘USER_NORM’ 不可使用）。
如果 R 尚未在目录树中创建，则必须按照主构建说明运行 configure。
然后（在 src/nmath/standalone 中）
make
将生成独立库 libRmath.a 和 libRmath.so（在 macOS 上为 libRmath.dylib）：‘make static’ 和 ‘make shared’ 将只创建其中一个。
要在您自己的 C 或 C++ 程序中使用这些例程，请包含
#define MATHLIB_STANDALONE #include <Rmath.h>
并链接到 ‘-lRmath’（如果您的操作系统需要，则还需要链接到 ‘-lm’）。示例文件 test.c 没有任何实际用途，但提供用于测试该过程（通过 make test）。请注意，除非您将包含 libRmath.so 的目录添加到 LD_LIBRARY_PATH 环境变量中（在 macOS 上为 libRmath.dylib，DYLD_FALLBACK_LIBRARY_PATH），否则您可能无法运行它。
目标
make install make uninstall
将（取消）安装头文件 Rmath.h 以及共享和静态 库（如果已构建）。prefix= 和 DESTDIR 都受支持，并提供更精确的控制，如主构建中所述。
‘make install’ 将安装一个文件供 pkg-config 使用，例如
$(CC) `pkg-config --cflags libRmath` -c test.c $(CC) `pkg-config --libs libRmath` test.o -o test
在某些系统上，‘make install-strip’ 将安装一个剥离的共享库。
您需要设置45几乎所有工具来构建 R，然后运行（在类 Unix shell 中）
(cd ../../gnuwin32; make MkRules) (cd ../../include; make -f Makefile.win config.h Rconfig.h Rmath.h) make -f Makefile.win
或者，在 cmd.exe shell 中使用
cd ../../include make -f Makefile.win config.h Rconfig.h Rmath.h cd ../nmath/standalone make -f Makefile.win
这将创建一个静态库 libRmath.a 和一个 DLL Rmath.dll。如果您想要一个导入库 libRmath.dll.a（您不需要它），请使用
make -f Makefile.win shared implib
要使用您自己的 C 或 C++ 程序中的例程，使用 MinGW-w64，请包含
#define MATHLIB_STANDALONE #include <Rmath.h>
并链接到 ‘-lRmath’。这将按顺序使用第一个找到的 libRmath.dll.a、libRmath.a 和 Rmath.dll，因此结果取决于哪些文件存在。您应该能够通过以下方式强制静态或动态链接通过
-Wl,-Bstatic -lRmath -Wl,Bdynamic -Wl,-Bdynamic -lRmath
或通过链接到显式文件（如 Makefile.win 中的 ‘test’ 目标：这将创建两个可执行文件，test.exe 是动态链接的，而 test-static.exe 是静态链接的）。
可以使用其他编译器链接到 Rmath.dll，直接或通过导入库：如果您像上面一样创建 MinGW-w64 导入库，您将创建一个文件 Rmath.def，该文件可用于（可能在编辑后）为其他系统（如 Visual C++）创建导入库。
如果您使用动态链接，您应该使用
#define MATHLIB_STANDALONE #define RMATH_DLL #include <Rmath.h>
以确保像 NA_REAL 这样的常量链接正确。（自动导入可能适用于 MinGW-w64，但最好确保。这很可能也适用于 VC++、Borland 和类似的编译器。）
本附录详细介绍了您在类 Unix 平台上构建 R 所需的程序，或者如果 configure 找到这些程序，R 将使用这些程序。
请记住，一些包管理系统（如 RPM 和 Debian/Ubuntu 的）区分了包的用户版本和开发版本。后者通常具有相同名称，但扩展名为 ‘-devel’ 或 ‘-dev’：您需要安装这两个版本。
您需要一种编译 C 和 Fortran 90 的方法（参见 使用 Fortran）。您的 C 编译器应符合 ISO/IEC 6005946、POSIX 1003.1 和 C99 标准。47 R 尝试为其已知的 C 编译器选择合适的标志48，但您可能需要适当地设置 CC 或 CFLAGS。（请注意，即使链接时也必须运行编译器的选项，例如设置体系结构的选项，应在 CC 中指定，而不是在 CFLAGS 中。）
除非您不想在屏幕上查看图形（或使用 macOS），否则您需要安装“X11”，包括其头文件和客户端库。对于最新的 Fedora/RedHat 发行版，这意味着（至少）RPMs“libX11”、“libX11-devel”、“libXt”和“libXt-devel”。在 Debian/Ubuntu 上，我们推荐元包“xorg-dev”。如果您真的不想使用这些，则需要使用 --with-x=no 显式地配置 R，使其不使用 X11。
命令行编辑（和命令补全）依赖于 GNU readline 库（包括其头文件）：版本 6.0 或更高版本是启用所有功能所必需的。否则，您需要使用 --with-readline=no（或等效选项）进行配置。
一个足够全面的 iconv 函数是必不可少的。R 的使用要求 iconv 能够在 "latin1" 和 "UTF-8" 之间进行转换，识别 ""（作为当前编码）和 "ASCII"，以及转换为和从 Unicode 宽字符格式 "UCS-[24][BL]E" 进行转换 - 对于 glibc49 来说，默认情况下这是正确的，但对于大多数商业 Unix 来说并非如此。但是，您可以使用 GNU libiconv（如 macOS 上所用：参见 https://www.gnu.org/software/libiconv/）。
操作系统需要对宽字符类型提供足够的支持50：这将在配置时进行检查。一些 C99 函数51 是必需的，并在配置时进行检查。少量 POSIX 函数52 是必不可少的，其他函数53 将在可用时使用。
需要安装 zlib（版本 1.2.5 或更高）、libbz2（版本 1.0.6 或更高：一些 Linux 发行版称为 bzip2-libs/bzip2-devel 或 libbz2-1.0/libbz2-dev）和 liblzma54 版本 5.0.3 或更高。
需要 PCRE1（版本 8.32 或更高，以前称为 PCRE）或 PCRE2：PCRE2 是首选，使用 PCRE1 需要 configure 选项 --with-pcre1。如果这些库和头文件是单独打包的，则只需要 8 位库和头文件。JIT 支持（可选）对于最佳性能是可取的。对于 PCRE2 >= 10.30（这是可取的，因为匹配已被重写为不使用递归，并且 Unicode 表已更新到版本 10）
./configure --enable-jit
就足够了。如果要构建 PCRE1 以供 R 使用，则合适的 configure 命令可能是
./configure --enable-utf --enable-unicode-properties --enable-jit --disable-cpp
--enable-jit 标志支持大多数常见 CPU，但对于“arm64”macOS 则不起作用（或根本不起作用）。
一些软件包需要“Unicode 属性”，这些属性对于 PCRE1 是可选的：可以通过调用 pcre_config() 在运行时检查对这些属性和 JIT 的支持。
需要库 libcurl（版本 7.28.0 或更高）。有关 libcurl 的信息可以在 curl-config 脚本中找到：如果该脚本丢失或需要覆盖55，则可以使用文件 config.site 中描述的宏来实现。
需要一个 tar 程序来解压缩源代码和软件包（包括推荐的软件包）。建议使用可以自动检测压缩档案的版本56 与 untar() 一起使用：配置脚本会在 tar 之前查找 gtar 和 gnutar – 使用环境变量 TAR 来覆盖此行为。（在 NetBSD/OpenBSD 系统上，如果安装了 bsdtar，则将其设置为 bsdtar。）
需要使用合适的 grep 和 sed 工具版本：问题通常出在旧的 AT&T 和 BSD 版本上。 configure 会尝试找到合适的版本（包括在 /usr/xpg4/bin 中查找，该目录在一些商业 Unix 系统上使用）。
除非安装了 texi2any 5.1 或更高版本（需要 perl），否则您将无法构建大多数手册，如果没有，大多数 HTML 手册将链接到 CRAN 上的版本。要制作手册的 PDF 版本，您还需要安装文件 texinfo.tex（它是 GNU texinfo 发行版的一部分，但在重新分发时通常被包含在 TeX 包中），以及 texi2dvi。57 此外，texi2dvi 和 texinfo.tex 的版本需要兼容：我们已经看到了旧的 TeX 发行版存在的问题。
如果您想从 R Subversion 仓库构建，那么强烈建议使用 texi2any，因为它用于创建包含在 tarball 中但未存储在 Subversion 仓库中的文件。
PDF 文档（包括 doc/NEWS.pdf）和构建示例需要 pdftex 和 pdflatex。我们要求 LaTeX 版本为 2005/12/01 或更高版本（以支持 UTF-8）。构建 PDF 包手册（包括 R 参考手册）和示例对 LaTeX 包 hyperref 的版本很敏感，我们建议使用最新的 TeX 发行版。PDF 手册需要一些标准的 LaTeX 包（包括 url 和一些字体包，例如 times 和 helvetic，以及 amsfonts），其他一些包，例如 hyperref 和 inconsolata 是可选的（如果没有它们，您可能需要更改 R 的默认设置：请参阅 制作手册）。请注意，包 hyperref（目前）需要包 kvoptions、ltxcmds 和 refcount，而 inconsolata 需要 xkeyval。构建基本示例需要 fancyvrb、natbib、parskip（目前需要 etoolbox）和 listings。对于基于 TeX Live 的发行版，最简单的方法可能是安装集合 collection-latex、collection-fontsrecommended、collection-latexrecommended、collection-fontsextra 和 collection-latexextra（假设它们不是默认安装的）：Fedora 使用类似 texlive-collection-fontsextra 的名称，而 Debian/Ubuntu 使用类似 texlive-fonts-extra 的名称。
程序 qpdf 和 ghostscript (gs) 是可选的，因为它们将用于压缩已安装的 PDF 示例和任何 PDF 手册。
在运行 configure 时，必需的程序应该在您的 PATH 中：这将捕获完整路径。
为了使日期时间正常工作，必须安装定义时区的表格：这些表格通常位于名为 tzdata 的操作系统组件中。在大多数操作系统上，它们是必需的，但已知 Alpine Linux 的安装没有它们。有一个 configure 检查，它可以确保在不同时区中正确使用最近的日期时间，这在从源代码安装时会捕获此问题（但对于二进制发行版则不会）。
分发 R 的二进制版本的人可能需要了解它所链接的外部库的许可证（包括下一节中“有用”的库）。liblzma 库是公有领域，而 X11、libbzip2、libcurl 和 zlib 则拥有 MIT 风格的许可证。PCRE 和 PCRE2 拥有 BSD 风格的许可证，要求在二进制分发中分发许可证（包含在 R 的 COPYRIGHTS 文件中）。GNU readline 则根据 GPL 许可（GPL 的版本取决于 readline 的版本）。
使用翻译后的消息的能力依赖于 gettext，并且很可能需要 GNU gettext：您需要它来处理新的翻译，但除此之外，如果找不到合适的外部 gettext，则将使用 R 源代码中包含的 gettext 运行时版本。
“现代”版本的 X11()、jpeg()、png() 和 tiff() 图形设备使用 Cairo 和 Pango 库。需要 Cairo 1.2.0 或更高版本以及 Pango 1.10 或更高版本（但目前版本要晚得多）。R 检查 pkg-config，并使用它首先检查是否安装了“pangocairo”包（如果没有，则检查“cairo”），然后检查是否可以编译合适的代码。如果未安装 pkg-config58，这些测试将失败，并且如果 cairo 是静态构建的，则可能会失败，除非使用 configure 选项 --with-static-cairo。大多数安装了 Gtk+ 2.8 或更高版本的系统将拥有合适的库：对于 Fedora 用户，pango-devel RPM 及其依赖项就足够了。有可能（但在拥有 X11 的平台上非常罕见）在没有 cairo-xlib 模块的情况下构建 Cairo，在这种情况下 X11(type = "cairo") 将不可用。Pango 是可选的，但非常理想，因为它很可能提供更好的文本渲染，包括字距调整。
为了获得这些设备的最佳字体体验，您需要安装合适的字体：Linux 用户将需要 urw-fonts 包。在有此包的平台上，msttcorefonts 包59 提供了诸如 Arial 和 Times New Roman 之类的 Monotype 字体的 TrueType 版本。另一套有用的字体是“liberation” TrueType 字体，可在 https://pagure.io/liberation-fonts60 获取，它涵盖了拉丁语、希腊语和西里尔字母以及相当范围的符号。这些字体与 Arial、Times New Roman 和 Courier New 的度量标准相同，并且包含与前两个字体非常相似的字体 (https://en.wikipedia.org/wiki/Liberation_fonts)。然后是“Free UCS Outline Fonts”项目 (https://www.gnu.org/software/freefont/)，它基于 URW 字体，但具有扩展的 Unicode 覆盖范围，是 OpenType/TrueType 字体。有关选择此类字体的更多信息，请参阅 R 中关于 X11 的帮助文档。
位图图形设备 jpeg()、png() 和 tiff() 需要安装相应的头文件和库：jpeg（版本 6b 或更高版本，或 libjpeg-turbo）或 libpng（版本 1.2.7 或更高版本）和 zlib 或 libtiff（已测试版本 4.0.[5-10] 和 4.[123].0）分别。如果可用，则使用 pkg-config，因此需要相应的 .pc 文件（需要 libtiff 版本 4.x，并且在所有平台上都不适用于 jpeg 版本 9c 之前的版本）。它们还需要 X11 或 cairo 的支持（见上文）。如果不需要对这些设备的支持，或者需要避免损坏的系统库，则可以使用 configure 选项 --without-libpng、--without-jpeglib 和 --without-libtiff。TIFF 库具有许多可选功能，例如 jpeg、libz、zstd、lzma、webp、jbig 和 jpeg12，这些功能对于 tiff() 设备来说都不是必需的，但可能需要存在才能链接库（通常只对静态链接是一个问题）。pkg-config 可以告诉您链接其他库需要哪些库，例如通过 pkg-config libtiff-4 --static --libs。
选项 --with-system-tre 也可用：它需要一个较新的 TRE 版本。（最新的源代码位于 git 存储库中，地址为 https://github.com/laurikari/tre/，但在撰写本文时，生成的构建没有完成其检查，R 也没有针对 Fedora 提供的版本进行构建。）
需要一个 XDR 实现，R 源代码包含一个可能足够使用的实现（尽管系统版本可能具有更高的性能）。XDR 是 RPC 的一部分，历史上一直是类 Unix 系统上 libc 的一部分。（原则上，man xdr_string 应该告诉您需要哪个库，但它通常不会这样做：在某些操作系统上，它由 libnsl 提供。）但是，某些 glibc 的构建61 会省略或隐藏它，目的是使用 TI-RPC 库，在这种情况下，应该安装 libtirpc（及其开发版本），并且其头文件62 需要位于 C 包含路径上或 /usr/include/tirpc 下。
使用 X11 剪贴板选择需要 Xmu 头文件和库。这些通常是 X11 安装的一部分（例如 Debian 元包 ‘xorg-dev’），但一些发行版将其拆分为更小的部分，因此例如 Fedora 的最新版本需要 ‘libXmu’ 和 ‘libXmu-devel’ RPM。
一些系统（特别是 macOS 和至少一些 FreeBSD 系统）对多字节区域设置中的排序支持不足。可以通过 ICU（Unicode 国际组件，https://icu.unicode.org/）来替换操作系统的排序支持，这在所有系统上提供了更精确的排序控制。ICU 可作为源代码和二进制发行版（至少）用于大多数 Linux 发行版、FreeBSD、macOS 和 AIX，通常为 libicu 或 icu4c。它将在可用时默认使用：如果发现非常旧或损坏的 ICU 版本，可以通过 --without-ICU 来抑制。
bitmap 和 dev2bitmap 设备以及函数 embedFonts() 使用 ghostscript (https://www.ghostscript.com/)。这应该在运行命令时位于您的路径中，或者其完整路径由环境变量 R_GSCMD 在那时指定。
在撰写本文时，Fedora Linux 上的完整安装使用了以下软件包及其开发版本，这可能为其他系统提供一个有用的清单
bzip2 cairo fontconfig freetype fribidi gcc gcc-gfortran gcc-c++ glib2 glibc harfbuzz lapack libX11 libXext libXt libcurl libicu libjpeg libpng libtiff libtirpc libxcrypt ncurses pango pkgconf-pkg-config pcre2 readline tcl tk xz zlib
此外，最好有一个 TeX 安装和 Java。
tcltk 包需要安装 Tcl/Tk ≥ 8.4：源代码可在 https://www.tcl.tk/ 获取。要指定 Tcl/Tk 文件的位置，您可能需要以下配置选项
使用 Tcl/Tk，或指定其库目录
指定 tclConfig.sh 的位置
指定 tkConfig.sh 的位置
或者使用配置变量 TCLTK_LIBS 和 TCLTK_CPPFLAGS 来指定链接到 Tcl 和 Tk 库所需的标志，以及查找 tcl.h 和 tk.h 头文件所需的标志。如果您同时安装了 32 位和 64 位版本的 Tcl/Tk，则可能需要指定指向正确配置文件的路径，以避免它们之间的混淆。
已测试 Tcl/Tk 版本（包括 8.4.x 的大多数版本，但最近没有测试）高达 8.5.19 和 8.6.12。
请注意，tk.h 头文件包含63 X11 头文件，因此您需要安装 X11 及其开发文件。
构建过程会在主机系统上查找 Java 支持，如果找到，它会设置一些对使用 Java 的包（例如 rJava 和 JavaGD：这些需要完整的 JDK）有用的设置。可以通过配置选项 --disable-java 来抑制此检查。 配置变量 JAVA_HOME 可以设置为指向特定的 JRE/JDK，在 configure 命令行或环境中设置。
这些设置中最重要的是指向 Java 库和 JVM 的一些路径，这些路径存储在环境变量 R_JAVA_LD_LIBRARY_PATH 中，位于文件 R_HOME/etc/ldpaths（或特定于子体系结构的版本）中。‘x86_64’ Linux 的典型设置是
JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc34.x86_64/jre
R_JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/amd64/server
不幸的是，这取决于安装的 JRE/JDK 的确切版本，因此如果 Java 安装更新，可能需要更新。这可以通过运行 R CMD javareconf 来完成，它会更新 R_HOME/etc/Makeconf 和 R_HOME/etc/ldpaths 中的设置。有关详细信息，请参见 R CMD javareconf --help：请注意，这需要由拥有 R 安装的帐户执行。
另一种覆盖这些设置的方法是设置环境变量 R_JAVA_LD_LIBRARY_PATH（在 R 启动之前，因此不在 ~/.Renviron 中），这足以运行已安装的 Java 使用的包。例如
R_JAVA_LD_LIBRARY_PATH=/usr/lib/jvm/java-1.8.0/jre/lib/amd64/server
可以通过在配置时指定一个不变的链接作为路径来避免这种情况。例如，在该系统上，以下任何一种
JAVA_HOME=/usr/lib/jvm/java JAVA_HOME=/usr/lib/jvm/java-1.8.0 JAVA_HOME=/usr/lib/jvm/java-1.8.0/jre JAVA_HOME=/usr/lib/jvm/jre-1.8.0
都有效（因为 /etc/alternatives 的“自动”设置选择了 Java 8，也称为 1.8.0）。
从版本 11 开始，Oracle 的“非服务器”版 Java 是一个完整的 JDK。但是，Linux 发行版可能会令人困惑：例如，Fedora 34 有
java-1.8.0-openjdk java-1.8.0-openjdk-devel java-openjdk java-openjdk-devel java-11-openjdk java-11-openjdk-devel java-17-openjdk java-17-openjdk-devel java-latest-openjdk java-latest-openjdk-devel
其中 -devel RPM 是完成 JDK 所必需的。Debian/Ubuntu 使用“-jre”和“-jdk”，例如
sudo apt install default-jdk
一些附加包需要 C++ 编译器。这由配置变量 CXX、CXXFLAGS 等指定。 configure 通常会找到合适的编译器。可以通过配置变量 CXX17、CXX17STD、CXX17FLAGS 等指定一个可选的 C++17 编译器（参见 C++ 支持）。同样，configure 通常会找到 CXX17STD 的合适值，前提是 CXX 指定的编译器能够编译 C++17 代码，但可能需要完全不同的编译器。（类似的宏适用于 C++20。）
对于扩展名为 .f90 或 .f95 的包含自由格式 Fortran 的源文件，R CMD INSTALL 使用由宏 FC 定义的编译器。请注意，它通过命令名称进行检测，而没有测试它是否能够实际编译 Fortran 90 代码。如果需要，请设置配置变量 FC 来覆盖此设置：变量 FCFLAGS 和 FCLIBS_XTRA 可能也需要设置。
有关这些变量的更多详细信息，请参见 R 源代码中的 config.site 文件。
R 中的线性代数例程使用 BLAS (基本线性代数子程序，https://netlib.org/blas/faq.html) 例程，并且大多数例程使用来自 LAPACK (线性代数包，https://netlib.org/lapack/) 的例程。R 源代码包含这些例程的参考（Fortran）实现，但它们可以被外部库替换，通常是针对特定 CPU 速度优化的库。这些库通常包含所有 BLAS 例程和一些经过优化的 LAPACK 例程，以及来自参考实现的其余 LAPACK 例程。由于链接方式的原因，使用外部 BLAS 库可能需要使用它包含的 LAPACK 版本。
请注意，替代实现不会给出完全相同的数值结果。一些差异可能是良性的（例如 SVD 和特征向量的符号），但优化后的例程可能不太准确，并且（特别是对于 LAPACK）可能来自较旧的版本，修复较少。但是，R 依赖于 ISO/IEC 60559 兼容性。如果例如代码假设具有零因子的项始终为零，并且不需要计算，则可能会破坏这种兼容性，而 x*0 可能为 NaN。内部 BLAS 已经过广泛的修补以避免这种情况，而 MKL 的文档则警告
LAPACK 例程假设输入矩阵不包含 IEEE 754 特殊值，例如 INF 或 NaN 值。使用这些特殊值可能会导致 LAPACK 返回意外结果或变得不稳定。
一些外部库是多线程的。一个问题是 R 分析（使用 SIGPROF 信号）可能会导致问题，如果您使用多线程 BLAS，您可能需要禁用分析。请注意，使用多线程 BLAS 可能会导致比使用类似的单线程 BLAS 占用更多 CPU 时间，甚至更多经过时间（有时会显著增加）。在运行其他任务的机器上，可能会出现争用 CPU 缓存，从而降低 BLAS 实现优化缓存使用的有效性：有些人警告说，对于超线程 CPU，这个问题尤其严重。
BLAS 和 LAPACK 例程可以在线程代码中使用，例如在 mgcv 等包中的 OpenMP 部分。参考实现是线程安全的，但外部实现可能不是（即使是单线程的）：这会导致难以追踪的错误结果或段错误。
R 的重新分发者倾向于使用“增强”的线性代数库，而没有解释其缺点。
必须在配置时显式请求外部 BLAS 库。
您可以通过配置选项 --with-blas 的值指定特定的 BLAS 库。如果该选项没有 =，则其值将从 环境变量 BLAS_LIBS 中获取，例如在 config.site 中设置。如果选项和环境变量都没有提供值，则会搜索合适的64 BLAS。如果该值不是明显的链接器命令（以破折号开头或给出库的路径），则会在其前面加上 ‘-l’，因此
--with-blas="foo"
是链接到 ‘-lfoo’ 以查找外部 BLAS 的指令（需要在链接时和运行时找到）。
配置代码会检查外部 BLAS 是否完整（截至 LAPACK 3.9.1：它必须包含所有双精度和双复数例程，以及 LSAME），并且似乎可用。但是，外部 BLAS 必须能够从共享对象中使用（因此必须包含位置无关代码），而这并没有检查。此外，BLAS 可以在运行配置后切换，无论是作为符号链接还是通过下面提到的机制，这可能会破坏完整性检查。
一些增强的 BLAS 是特定于编译器系统的（macOS 上的 Accelerate，Solaris 上的 sunperf65，IBM 上的 libessl）。这些的正确调用方式通常可以在适当的平台上通过 --with-blas 找到，并且不需要在该选项后面添加任何值。
请注意，在 Unix 下（但在 Windows 下不行），如果 R 是针对非默认 BLAS 编译的，并且没有使用 --enable-BLAS-shlib（它是在除 AIX 之外的所有平台上的默认设置），那么所有使用 BLAS 的包也必须如此。因此，如果 R 被重新构建以使用增强的 BLAS，那么诸如 quantreg 之类的包将需要重新安装。
Debian/Ubuntu 系统提供了一种特定于系统的方式来切换正在使用的 BLAS：使用 --with-blas 构建 R 以选择操作系统版本的参考 BLAS，然后使用 update-alternatives 在可用的 BLAS 库之间切换。请参阅 https://wiki.debian.org/DebianScience/LinearAlgebraLibraries。
Fedora 33 及更高版本提供“FlexiBLAS”，这是一种类似的机制，用于切换正在使用的 BLAS (https://www.mpi-magdeburg.mpg.de/projects/flexiblas)。但是，它不是覆盖 libblas，而是需要使用选项 --with-blas=flexiblas 配置 R。“后端”包装器可用于参考 BLAS、ATLAS 以及 OpenBLAS 和 BLIS 的串行、线程化和 OpenMP 版本。这可以通过包 flexiblas 在运行的 R 会话中进行控制。
使用并行计算的 BLAS 实现可能是非确定性的：这在 ATLAS 中是已知的。
ATLAS (https://math-atlas.sourceforge.net/) 是一个“调整过的”BLAS，它可以在各种类 Unix 平台上运行。不幸的是，它默认情况下被构建为一个静态库，在某些平台上可能无法与 R 包中使用的共享对象一起使用。在使用预构建版本的 ATLAS 静态库时要小心（它们似乎在“ix86”平台上有效，但在“x86_64”平台上并不总是有效）。
ATLAS 包含少量 LAPACK 例程的替换，但可以构建为将这些替换与参考 LAPACK 源代码合并，以包含完整的 LAPACK 库。
最新版本的 ATLAS 可以构建为单个共享库，无论是 libsatlas 还是 libtatlas（分别为串行或线程）：它们甚至可以包含完整的 LAPACK。这些构建可以通过以下方式使用
--with-blas=satlas --with-blas=tatlas
或者，像在 ‘x86_64’ Fedora 上，需要指定路径，
--with-blas="-L/usr/lib64/atlas -lsatlas" --with-blas="-L/usr/lib64/atlas -ltatlas"
分布式 ATLAS 库无法针对您的机器进行调整，因此是一种折衷方案：例如，Fedora 针对具有 SSE3 扩展的 CPU 调整 ‘x86_64’ RPM，并且可能提供针对特定 CPU 系列的单独 RPM。
请注意，在 Linux 上针对分布式共享库构建 R 可能需要安装 ‘-devel’ 或 ‘-dev’ 包。
链接多个静态库需要以下之一
--with-blas="-lf77blas -latlas" --with-blas="-lptf77blas -lpthread -latlas" --with-blas="-L/path/to/ATLAS/libs -lf77blas -latlas" --with-blas="-L/path/to/ATLAS/libs -lptf77blas -lpthread -latlas"
请参阅其安装指南67，了解如何将 ATLAS 构建为共享库或构建为具有位置无关代码的静态库（在相关平台上）。
根据 ATLAS 常见问题解答68，多线程 ATLAS 使用的最大线程数在编译时设置。此外，作者建议不要在超线程 CPU 上使用多线程 ATLAS，除非在编译时将亲和性限制为每个物理 CPU 一个虚拟核心。（对于 Fedora 库，编译时标志指定 4 个线程。）
Goto Kazushige 博士为多个处理器和操作系统编写了一个经过调整的 BLAS，该库在 2010 年被冻结。OpenBLAS (https://www.openblas.net/) 是一个后继项目，支持一些更新的 CPU。
这可以通过使用类似以下内容配置 R 来使用
--with-blas="openblas"
请参阅 共享 BLAS，了解使用它们的另一种（在许多方面更可取）方法。
一些平台提供 OpenBLAS 的多个版本：例如，Fedora 有 RPMs69
openblas openblas-threads openblas-openmp
提供共享库
libopenblas.so libopenblasp.so libopenblaso.so
分别，每个都可以用作共享 BLAS。对于第二个和第三个，线程数分别由 OPENBLAS_NUM_THREADS 和 OMP_NUM_THREADS 控制（与 OpenMP 一样）。
这些库及其 Debian 等效库包含完整的 LAPACK 实现。
请注意，在 Linux 上针对分布式库构建 R 可能需要安装 ‘-devel’ 或 ‘-dev’ 包。
对于“ix86”和“x86_64” CPU，大多数分布式库包含针对不同 CPU 微架构的多个备选方案，并在运行时进行选择。
另一个衍生项目是 BLIS (https://github.com/flame/blis)。它在 Fedora 中有共享库
libblis.so libblisp.so libbliso.so
(p 代表“线程”，o 代表 OpenMP，与 OpenBLAS 相同)，也可以用作共享 BLAS。Fedora 构建的 BLIS 库中不包含 LAPACK。
对于英特尔处理器（以及其他一些处理器）和一些 Linux 发行版，存在英特尔的数学内核库70。建议您在尝试链接到 MKL 之前阅读随库安装的文档。这包括一个“链接行顾问”，它将建议合适的咒语：建议使用它。或者参见 https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl-link-line-advisor.html#gs.vpt6qp（在撰写本文时，它选择了英特尔库用于与 GCC 链接）。
MKL 也有 macOS71 和 Windows 版本，但当尝试使用这些版本时，它们无法与这些平台上用于 R 的默认编译器一起使用。
以下示例已在 MKL 10.3 到 2023.2.0 版本中使用，适用于“x86_64” CPU 上的 GCC 编译器。（另请参见 英特尔编译器。）
要使用 MKL 的顺序版本，我们使用了
MKL_LIB_PATH=/path/to/intel_mkl/mkl/lib/intel64
export LD_LIBRARY_PATH=$MKL_LIB_PATH
MKL="-L${MKL_LIB_PATH} -lmkl_gf_lp64 -lmkl_core -lmkl_sequential"
./configure --with-blas="$MKL" --with-lapack
使用 --with-lapack 选项，因为 MKL 包含一个经过优化的 LAPACK 副本（通常比当前版本旧），以及 BLAS（参见 LAPACK），尽管可以省略此选项。
可以通过用以下内容替换定义变量 MKL 的行来使用带线程的 MKL
MKL="-L${MKL_LIB_PATH} -lmkl_gf_lp64 -lmkl_core \
-lmkl_gnu_thread -dl -fopenmp"
R 也可以链接到一个单独的共享库 libmkl_rt.so，用于 BLAS 和 LAPACK，但必须通过环境变量选择正确的 OpenMP 和 MKL 接口层。对于 64 位构建和 GCC 编译器，我们使用
export MKL_INTERFACE_LAYER=GNU,LP64 export MKL_THREADING_LAYER=GNU
在 Debian/Ubuntu 上，MKL 由软件包 intel-mkl-full 提供，并且可以在安装软件包期间将 libmkl_rt.so 设置为 BLAS 和 LAPACK 的系统范围实现，以便从 Debian/Ubuntu 软件包 r-base 安装的 R 也会使用它。但是，在运行 R 之前设置 MKL_INTERFACE_LAYER 和 MKL_THREADING_LAYER 仍然至关重要，否则 MKL 计算将产生不正确的结果。R 不需要重新构建即可使用 MKL，但 configure 包含测试，这些测试可能会发现一些错误，例如未能设置正确的 OpenMP 和 MKL 接口层。
请注意，Debian/Ubuntu 发行版可能非常旧（例如，在 2023 年中期，当 2023.1 是当前版本时，2020.4 是当前版本）：这对于所包含的 LAPACK 版本可能很重要。
默认线程数将由 OpenMP 软件选择，但可以通过设置 OMP_NUM_THREADS 或 MKL_NUM_THREADS 来控制，并且在最近的版本中，似乎默认情况下会为机器的单独使用选择一个合理的值。（并行 MKL 并不总是通过 make check-all，但在 MKL 2019.4 及更高版本中通过了。）
MKL 包含 FFTW3 的部分实现，这会给需要 MKL 不支持的某些 FFTW3 功能的应用程序带来麻烦。请参阅 MKL 手册以了解这些限制的描述以及有关如何创建排除 FFTW3 包装器的 MKL 自定义版本的说明。
Intel 有关于使用 MKL 构建 R 的文档，位于 https://www.intel.com/content/www/us/en/developer/articles/technical/using-onemkl-with-r.html：其中包括
-Wl,--no-as-needed
我们发现没有必要。
如果在配置 R 时发现版本为 3.10.0 或更高（且不包含 BLAS 例程）的系统 LAPACK 库，则将使用该库，而不是编译包源代码中的 LAPACK 代码。可以通过使用 --without-lapack 选项配置 R 来阻止这种情况。不支持使用静态 liblapack.a 文件。
假设 -llapack 是参考 LAPACK 库，但在 Debian/Ubuntu 上，它可以被切换，包括在 R 安装之后。在这样的平台上，最好明确使用 --without-lapack 或 --with-blas --with-lapack（见下文）。已知的非参考 LAPACK 库示例72 在安装时都包含 BLAS 例程，因此不会被默认的 configure 运行使用。
提供了使用 --with-lapack 选项指定外部 LAPACK 库的机制，主要是为了处理包含 LAPACK 副本的 BLAS 库（例如 macOS 上的 Accelerate 以及 ‘ix86’/‘x86_64’ Linux 上的某些 ATLAS、FlexiBLAS、MKL 和 OpenBLAS 版本）。至少需要 LAPACK 版本 3.2。只有在使用 --with-blas 选项时才能执行此操作。
但是，预计性能提升很小（甚至可能为负）。默认情况下不会搜索合适的 LAPACK 库，并且强烈建议不要这样做。您可以通过配置选项 --with-lapack 指定特定的 LAPACK 库或搜索通用库，而无需指定任何值。对于 --with-lapack，默认情况下会检查 BLAS 库（用于函数 DPSTRF），然后查找外部库 ‘-llapack’。希望获得最快线性代数运算速度的站点可能希望使用 ATLAS 优化的 LAPACK 子集构建 LAPACK 库。类似地，OpenBLAS 可以构建为包含优化的 LAPACK 子集或完整的 LAPACK（后者似乎是默认设置）。
可以通过环境变量 LAPACK_LIBS 设置 --with-lapack 的值，但只有在指定 --with-lapack 并且 BLAS 库不包含 LAPACK 时才会使用该值。
请注意，使用 --with-lapack 仅在某些平台上必要，以及一些用户想要尝试声称的性能改进时才提供。实际上，它的主要用途是：
liblapack，可以通过“alternatives”机制进行切换。
与所有库一样，您需要确保它们和 R 使用兼容的编译器和标志进行编译。例如，这意味着在 Sun Sparc 上使用 Oracle 编译器，如果要使用 sunperf，则需要 -dalign 标志。
在某些系统上，需要使用与构建 R 相同的 Fortran 编译器构建外部 BLAS/LAPACK。
使用最新版本的 gfortran 构建的 BLAS 和 LAPACK 库需要来自 C/C++ 的调用来处理“隐藏”的字符长度——R 本身会这样做，但许多包以前没有这样做，并且有些包出现了段错误。这在很大程度上通过使用 Fortran 标志 -fno-optimize-sibling-calls（以前由 configure 在检测到 gfortran 7 或更高版本时设置）来解决：但是，在包中不再可选地使用包含这些字符长度参数的 R 头文件。
LAPACK 3.9.0（以及可能更早的版本）存在一个错误，其中 DCOMBSSQ 子例程可能会导致 NA 被解释为零。这在 R 3.6.3 及更高版本的源代码中已修复，但如果您使用外部 LAPACK，则可能需要在那里修复它。（该错误在 3.9.1 中已修复，该例程在 3.10.1 中已删除。）
代码（在 dlapack.f 中）应为
* ..
* .. Executable Statements ..
*
IF( V1( 1 ).GE.V2( 1 ) ) THEN
IF( V1( 1 ).NE.ZERO ) THEN
V1( 2 ) = V1( 2 ) + ( V2( 1 ) / V1( 1 ) )**2 * V2( 2 )
ELSE
V1( 2 ) = V1( 2 ) + V2( 2 )
END IF
ELSE
V1( 2 ) = V2( 2 ) + ( V1( 1 ) / V2( 1 ) )**2 * V1( 2 )
V1( 1 ) = V2( 1 )
END IF
RETURN
（LAPACK 3.9.0 中缺少内部 ELSE 子句。）
如果您确实使用外部 LAPACK，请注意 LAPACK 源代码中其他错误（或发布的这些源代码的更正）的潜在问题，这些问题多年来在 Linux 发行版中多次出现。我们甚至看到发行版中缺少 LAPACK 例程，这些例程来自他们的 liblapack。
我们依赖 LAPACK 中对具有 2^{31} 或更多元素的矩阵的有限支持：外部 LAPACK 可能不支持该支持。
configure 有许多选项: 运行
./configure --help
将列出所有选项。可能最重要的选项（括号内为默认值）如下：
使用 X Window 系统 [yes]
X 包含文件位于 DIR
X 库文件位于 DIR
使用 readline 库（如果可用） [yes]
尝试编译对 Rprof() 的支持 [yes]
尝试编译对 Rprofmem() 和 tracemem() 的支持 [no]
将 R 构建为共享/动态库 [no]
将 BLAS 构建为共享/动态库 [yes, 除了在 AIX 上]
您可以使用 --without-foo 或 --disable-foo 来表示否定。
如果您要构建 R 的已分析可执行文件（例如，使用 ‘-pg)’），则需要使用 --disable-R-profiling。对 R 分析的支持需要操作系统对 POSIX 线程（也称为 ‘pthreads’）的支持，这些线程在所有主流类 Unix 系统平台上都可用。
标志 --enable-R-shlib 会导致 make 过程将 R 构建为动态（共享）库，通常称为 libR.so，并将主 R 可执行文件 R.bin 链接到该库。这只有在所有代码（包括系统库）都可以编译成动态库的情况下才能完成，并且可能会导致性能73下降。因此，您可能只希望在使用嵌入 R 的应用程序时才使用此选项。请注意，在与 --enable-R-shlib 链接的 R 系统上安装的包中的 C 代码会链接到动态库，因此这些包无法从以默认方式构建的 R 系统中使用。此外，由于包链接到 R，因此在某些操作系统上，它们也会链接到 R 本身链接到的动态库，这会导致符号冲突。
为了最大限度地有效使用 valgrind，R 应该使用 valgrind 监测工具进行编译。 configure 选项是 --with-valgrind-instrumentation=level，其中 level 为 0、1 或 2。（级别 0 为默认值，不添加任何内容。）如果存在 valgrind 的系统头文件，则将使用它们（在 Linux 上，它们可能位于单独的包中，例如 valgrind-devel）。但请注意，不能保证 R 中的代码与非常旧的74 或未来的 valgrind 头文件兼容。
如果您需要使用不同的选项重新配置 R，则可能需要在执行此操作之前运行 make clean 甚至 make distclean。
configure 脚本包含由 autoconf 添加的其他通用选项，这些选项不支持 R：特别是，在不同主机上为一种架构构建是不可能的。
除非通过配置选项 --disable-nls 禁用，否则消息翻译将通过 GNU gettext 支持。如果已编译支持，则 configure 报告将显示 NLS 作为“附加功能”之一，并且在英文区域设置（但不是 C 区域设置）中运行将包括
Natural language support but running in an English locale
在启动 R 时的问候语中。
如果您需要或希望将某些配置变量设置为非默认值，可以通过编辑文件 config.site（该文件记录了您可能想要设置的许多变量：其他变量可以在文件 etc/Renviron.in 中看到）或在命令行中执行以下操作：
./configure VAR=value
如果您在与源代码不同的目录中构建，则源代码目录和构建目录中可能存在 config.site 的副本，并且将读取这两个副本（按此顺序）。此外，如果存在文件 ~/.R/config，则会在源代码目录和构建目录中的 config.site 文件之间读取该文件。
还有一种通用的 autoconf 机制用于 config.site 文件，这些文件在上一段提到的任何文件之前读取。它首先查看由 环境变量 CONFIG_SITE 指定的文件，如果未设置，则查看诸如 /usr/local/share/config.site 和 /usr/local/etc/config.site 之类的文件，这些文件位于 R 将要安装的区域（以 /usr/local 为例）。
这些变量是 宝贵的，这意味着它们不需要导出到环境中，即使在命令行上未指定，也会保留在缓存中，在两次配置运行之间检查一致性（前提是使用缓存），并且在自动重新配置期间保留，就像作为命令行参数传递一样，即使没有使用缓存。
有关所有这些变量的列表，请参阅 configure --help 的变量输出部分。
如果您发现需要更改配置变量，请注意某些设置可能会缓存在 config.cache 文件中，并且在重新配置之前删除该文件（如果存在）是一个好主意。请注意，默认情况下缓存已 关闭：使用命令行选项 --config-cache（或 -C）启用缓存。
一个常见的要更改的变量是 R_PAPERSIZE，它默认为 ‘a4’，而不是 ‘letter’。（有效值为 ‘a4’，‘letter’，‘legal’ 和 ‘executive’。）
这在配置 R 以设置默认值以及运行 R 以覆盖默认值时使用。它还用于在制作 PDF 手册时设置纸张大小。
如果 R_PAPERSIZE 未设置，则配置默认值通常为 ‘a4’。（如果找到程序 paperconf，它存在于许多 Linux 发行版中， 或环境变量 PAPERSIZE 已设置，则使用它们来生成默认值。）
另一个重要的变量是 R_BROWSER，它代表默认的 HTML 浏览器，其值应为用户路径中的可执行文件或指定完整路径。
它在 PDF 文件中的对应变量是 R_PDFVIEWER。
如果您在非系统目录中拥有库和头文件，例如 GNU readline，请分别使用变量 LDFLAGS（用于库，使用 ‘-L’ 标志传递给链接器）和 CPPFLAGS（用于头文件，使用 ‘-I’ 标志传递给 C/C++ 预处理器）来指定这些位置。这些变量默认值为 ‘-L/usr/local/lib’ (LDFLAGS，在大多数 64 位 Linux 操作系统上为 ‘-L/usr/local/lib64’) 和 ‘-I/usr/local/include’ (CPPFLAGS，但请注意，在大多数系统上，/usr/local/include 被视为系统包含目录，因此该宏中的实例将被跳过)，以涵盖最常见的情况。如果仍然找不到库，那么您的编译器/链接器可能不支持重新排序 -L 和 -l 标志。在这种情况下，请使用不同的编译器（或使用一个前端 shell 脚本来进行重新排序）。
这些标志还可以用于构建运行速度更快的 R 版本。在大多数使用 gcc 的平台上，在 CFLAGS 和 FFLAGS 中包含 ‘-O3’ 可以使用 gcc 和 gfortran 获得显著的性能提升，但可能会导致构建结果不太可靠（已观察到段错误和不正确的数值计算）。在使用 GNU 链接器（尤其是那些将 R 作为共享库使用的系统）上，在 LDFLAGS 中包含 ‘-Wl,-O1’ 可能会有所帮助，并且建议在 https://lwn.net/Articles/192624/ 中使用 ‘'-Bdirect,--hash-style=both,-Wl,-O1'’。将编译调整到特定的 CPU 系列（例如，对于 gcc 使用 ‘-mtune=native’）可以获得显著的性能提升，尤其是在较旧的体系结构（如 ‘ix86’）上。
默认情况下，shell 脚本（如 R）将是 ‘#!/bin/sh’ 脚本（或使用 SHELL，由 configure 选择）。这几乎总是令人满意的，但在少数系统上，/bin/sh 不是 Bourne shell 或其克隆，可以使用配置变量 R_SHELL 设置要使用的 shell，该变量的值应为 shell 的完整路径（例如 /usr/local/bin/bash）。
要在单独的目录中构建，您需要一个支持 VPATH 变量的 make，例如 GNU make 和 dmake。
如果您想使用另一个名称的 make，例如，如果您的 GNU make 被称为 ‘gmake’，您需要在配置时设置变量 MAKE，例如
./configure MAKE=gmake
要编译 R，您需要一个 Fortran 90 编译器。当前默认情况下会搜索 gfortran、g95、xlf95 f95、fort、ifort、ifc、efc、pgfortran、pgf95 lf95、ftn、nagfor、xlf90、f90、pgf90、pghpf、epcf90。（请注意，这些是按名称搜索的，不检查它们支持的 Fortran 标准。）使用的命令和标志应支持扩展名为 .f 的固定格式 Fortran：在需要为扩展名为 .f90 或 .f95 的自由格式 Fortran 使用特定标志的罕见情况下，可以在 FCFLAGS 中指定该标志。
可以使用配置变量 FC 更改搜索机制，该变量指定运行 Fortran 编译器的命令。如果您的 Fortran 编译器位于非标准位置，您应该 在运行 configure 之前相应地设置环境变量 PATH，或者使用配置变量 FC 指定其完整路径。
如果您的 Fortran 库位于稍微特殊的位置，您应该 也查看 LD_LIBRARY_PATH（或您的系统等效项）以确保所有库都在此路径上。
请注意，只支持将标识符转换为小写的 Fortran 编译器。
您必须设置任何必要的编译标志（如果有）以确保 Fortran integer 等效于 C int 指针，而 Fortran double precision 等效于 C double 指针。这将在配置过程中进行检查。
一些 Fortran 代码使用了 DOUBLE COMPLEX 和 COMPLEX*16 变量。这在配置时进行检查，以及它与 R_ext/Complex.h 中定义的 Rcomplex C 结构的等效性。
gfortran 10 默认情况下会对以前广泛使用的将 Fortran 数组元素传递给期望数组的位置，或将标量传递给长度为一的数组的做法给出编译错误。请参阅 https://gcc.gnu.org/gcc-10/porting_to.html。 gfortran 12 在更多情况下会出错。
可以在 config.site 文件中或作为命令行上的配置变量设置各种标志。我们已经提到了
CPPFLAGS头文件搜索目录 (-I) 和 C 和 C++ 预处理器和编译器的任何其他杂项选项
LDFLAGS路径 (-L)，剥离 (-s) 和链接器的任何其他杂项选项
以及其他包括
CFLAGS调试和优化标志，C
MAIN_CFLAGS同上，用于编译主程序（例如，在分析时）
SHLIB_CFLAGS用于共享对象（没有已知示例）
FFLAGS调试和优化标志，固定格式 Fortran
FCFLAGS调试和优化标志，自由格式 Fortran
SAFE_FFLAGS同上，用于需要精确浮点行为的源文件
MAIN_FFLAGS同上，用于编译主程序（例如，在分析时）
SHLIB_FFLAGS用于共享对象（没有已知示例）
MAIN_LDFLAGS主链接的附加标志
SHLIB_LDFLAGS链接共享对象的附加标志
LIBnn主库目录，lib 或 lib64
CPICFLAGS用于将 C 代码编译成共享对象的特殊标志
FPICFLAGS用于将 Fortran 代码编译成共享对象的特殊标志
CXXPICFLAGS用于将 C++ 代码编译成共享对象的特殊标志
DEFS在 R 本身中编译 C 代码时要使用的定义
在 LDFLAGS 中指定为 -L/lib/path 的库路径将 收集在一起并预先添加到 LD_LIBRARY_PATH（或您的系统等效项）中，因此不需要 -R 或 -rpath 标志。
像 CPICFLAGS 这样的变量在可能的情况下由 configure 确定。某些系统允许两种类型的 PIC 标志，例如 ‘-fpic’ 和 ‘-fPIC’，如果它们不同，第一个只允许共享对象中包含有限数量的符号。由于 R 作为共享库大约有 6200 个符号，如果存在疑问，请使用较大的版本。
其他由 configure 设置的变量通常包括 ‘MAIN_LDFLAGS’, ‘SAFE_FFLAGS’, ‘SHLIB_LDFLAGS’ 和 ‘SHLIB_CXXLDFLAGS’：有关这些变量和其他变量的更多文档，请参见源代码中的 config.site 文件。
要编译 R 的性能分析版本，例如，您可能希望在平台上使用 ‘MAIN_CFLAGS=-pg’, ‘MAIN_FFLAGS=-pg’, ‘MAIN_LDFLAGS=-pg’，其中 ‘-pg’ 不能与位置无关代码一起使用。
注意：可能需要以与要使用的库兼容的方式设置 CFLAGS 和 FFLAGS：一个可能的问题是双精度数的对齐方式，另一个是结构传递的方式。
在某些平台上，configure 将在 R_XTRA_CFLAGS（以及其他）中为 CFLAGS、CPPFLAGS 和 LIBS 选择额外的标志。这些标志用于始终需要的选项，例如强制执行 IEC 60559 兼容性。
有几个文件是 R 源代码的一部分，但可以通过使用 --enable-maintainer-mode 选项配置并随后在构建目录中运行 make 来从其自身源代码重新生成。这需要安装其他工具，将在本节的其余部分讨论。
文件 configure 是由 autoconf 和 aclocal（automake 包的一部分）从 configure.ac 和 m4 下的文件创建的。对 autoconf 有一个正式的版本要求，即 2.69 或更高版本，但除了最新版本75之外，其他版本可能没有经过彻底测试。
文件 src/include/config.h 是由 autoheader（autoconf 的一部分）创建的。
语法文件 *.y 由 yacc 的实现（通常是 bison -y）转换为 C 源代码：这些文件位于 src/main 和 src/library/tools/src 中。已知早期版本的 bison 生成的代码会在数组边界之外读取（在某些情况下还会写入）：bison 2.6.1 被发现是令人满意的。
包 compiler 的最终源代码位于其 noweb 目录中。要从 src/library/compiler/noweb/compiler.nw 重新创建源代码，需要使用 notangle 命令。一些 Linux 发行版将此命令包含在包 noweb 中。它也可以从 https://www.cs.tufts.edu/~nr/noweb/76 的源代码中安装。即使在维护者模式下，也只有在 src/library/compiler/noweb/compiler.nw 更新后才会重新创建包源代码。
本节提供一些关于在不同类 Unix 平台上构建 R 的说明。这些说明基于在每个平台上的一两个系统上运行的测试，使用特定的编译器和支持库集。成功构建 R 取决于支持软件的正确安装和运行；如果您使用其他版本的编译器和支持库，您的结果可能会有所不同。
本手册的旧版本包含有关 HP-UX、IRIX、Alpha/OSF1（针对 R < 2.10.0，并且此后已删除对所有这些平台的支持）和 AIX（针对 R < = 3.5.x）的说明，我们最近没有收到有关这些平台的报告。
用于选择特定平台的 C 宏可能很难追踪（网络上有很多错误信息）。https://sourceforge.net/p/predef/wiki/Home/ 上的 Wiki（目前）可能会有所帮助。R 源代码使用（通常在 src/extra 下的包含软件中）
AIX: _AIX Cygwin: __CYGWIN__ FreeBSD: __FreeBSD__ HP-UX: __hpux__, __hpux IRIX: sgi, __sgi Linux: __linux__ macOS: __APPLE__ NetBSD: __NetBSD__ OpenBSD: __OpenBSD__ Windows: _WIN32, _WIN64
识别编译器可能非常棘手。GCC 定义了 __GNUC__，但其他声称符合 GCC 的编译器也定义了它，特别是（LLVM 和 Apple）clang 和 Intel 编译器。此外，一些编译器使用 __GNUC__ 的值来表示其版本，而不是它们声称兼容的 GCC 版本。77 基于 clang 的编译器定义 __clang__。LLVM 和 Apple clang 都定义 __clang_major__ 作为表示其主要版本的字符串，但例如 Apple 的 13.x.y 与 LLVM 的 13.x.y 非常不同。基于 LLVM clang 的编译器，例如来自 Intel 和 IBM 的编译器，也会定义这些宏。一些包含的软件使用 __APPLE_CC__ 来识别 Apple 编译器（以前包括 Apple 构建的 GCC），但 Apple clang 最好通过 __apple_build_version__ 宏来识别。
在 Unix 类系统（大多数 macOS 版本除外）上绘图时，‘X11()’ 图形设备会自动启动。顾名思义，它在（本地或远程）X 服务器上显示，并依赖于 X 服务器提供的服务。
‘X11()’ 设备的“现代”版本基于 ‘cairo’ 图形，并且（在大多数实现中）使用 ‘fontconfig’ 来选择和渲染字体。这在服务器上完成，虽然可能存在选择问题，但它们比本节其余部分讨论的 ‘X11()’ 问题更容易解决。
X11 设计之初，大多数显示器的分辨率约为 75dpi，而如今它们的分辨率已达到 100dpi 或更高。如果您发现 X11() 报告78缺少字体大小，尤其是较大的字体大小，则可能是您没有使用可缩放字体，并且没有安装 X11 字体的 100dpi 版本。名称和细节因系统而异，但可能类似于 Fedora 的
xorg-x11-fonts-75dpi xorg-x11-fonts-100dpi xorg-x11-fonts-ISO8859-2-75dpi xorg-x11-fonts-Type1 xorg-x11-fonts-cyrillic
您需要确保安装了 ‘-100dpi’ 版本，并且它们位于 X11 字体路径上（通过 xset -q 检查）。‘X11()’ 设备确实会尝试设置点大小而不是像素大小：笔记本电脑用户可能会发现默认设置 12 太大（尽管笔记本电脑屏幕通常设置为虚假 dpi 以显示为缩小的桌面屏幕）。
在非西欧语言环境中可能会出现更复杂的问题，因此如果您使用的是非西欧语言环境，首先要检查的是在 C 语言环境中是否正常工作。可能出现的问题是无法找到任何字体或字形渲染不正确（通常为一对 ASCII 字符）。X11 的工作原理是请求字体规范，并提供其认为最接近的匹配。对于文本（与 plotmath 使用的符号不同），规范是选项 "X11fonts" 的第一个元素，默认值为
"-adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*"
如果您使用的是单字节编码，例如东欧的 ISO 8859-2 或俄语的 KOI8-R，请使用 xlsfonts 在您的编码中查找合适的字体系列（列表中的最后一个字段）。如果您没有找到，则可能需要安装更多字体包，例如上面列表中显示的“xorg-x11-fonts-ISO8859-2-75dpi”和“xorg-x11-fonts-cyrillic”。
多字节编码（最常见的是 UTF-8）更加复杂。在“iso10646-1”（Unicode 编码）中只有很少的字体，而且它们只包含可用字形的子集（并且通常是为终端使用而设计的固定宽度）。在这样的区域设置中，使用 字体集，这些字体集由以其他编码编码的字体组成。如果您使用的区域设置在“XLC_LOCALE”目录（通常是 /usr/share/X11/locale）中有一个条目，那么您可能只需要选择一个合适的字体规范，该规范包含在其中指定的编码中的字体。如果没有，您可能需要获取一个适合 X11 的区域设置条目。这意味着，例如，在“ja_JP.UTF-8”中运行时可以显示日语文本，但在同一台机器上的“en_GB.UTF-8”中运行时则不能（尽管在某些系统上，许多 UTF-8 X11 区域设置被别名为“en_US.UTF-8”，它涵盖了多个字符集，例如 ISO 8859-1（西欧）、JISX0208（汉字）、KSC5601（韩语）、GB2312（汉语）和 JISX0201（假名））。
在某些系统上，可用的可缩放字体涵盖了广泛的字形。一个来源是 TrueType/OpenType 字体，它们可以提供高覆盖率。另一个是 Type 1 字体：URW 的 Type 1 字体集提供了标准的字体，例如 Helvetica，它比标准的 X11 位图包含更多 Unicode 字形的覆盖率，包括西里尔字母。这些通常不是默认安装的一部分，并且可能需要配置 X 服务器才能使用它们。它们可能位于 X11 的 fonts 目录或其他位置，例如：
/usr/share/fonts/default/Type1 /usr/share/fonts/ja/TrueType
Linux 是 R 的主要开发平台，因此使用最常见的编译器和库从源代码进行编译通常很简单。 79
本节介绍 GCC 编译器：gcc/gfortran/g++。
请记住，一些包管理系统（如 RPM 和 deb）区分了包的用户版本和开发人员版本。后者通常具有相同的名称，但扩展名为“-devel”或“-dev”：您需要安装这两个版本。因此，请检查 configure 输出以查看是否检测到预期功能：例如，如果缺少“readline”，请添加开发人员包。（在大多数系统上，您还需要“ncurses”及其开发人员包，尽管这些应该是“readline”包的依赖项。）您应该在 configure 摘要中看到
Interfaces supported: X11, tcltk External libraries: pcre2, readline, curl Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU
当 R 从二进制发行版安装时，有时会遇到缺少组件的问题，例如 Fortran 编译器。搜索“R-help”档案通常会显示需要什么。
似乎“ix86”Linux 接受共享库中的非 PIC 代码，但这在其他平台上并不一定如此，特别是在 64 位 CPU 上，例如“x86_64”。因此，在构建 R 作为共享库时，需要谨慎处理 BLAS 库，以确保在任何静态库（例如 Tcl/Tk 库、libpng、libjpeg 和 zlib）中使用位置无关代码，这些库可能与之链接。幸运的是，除了 ATLAS BLAS 库之外，这些库通常被构建为共享库。
为 CFLAGS 等选择的默认优化设置比较保守。使用 -mtune 很可能在最新的 CPU 上带来显著的性能提升：一种可能性是添加 -mtune=native，以便在安装 R 的机器上获得最佳性能。还可以将优化级别提高到 -O3：但是，对于许多版本的编译器来说，这在至少一个 CRAN 包中造成了问题。
不要将 -O3 与 gcc 11.0 或 11.1 一起使用：它会错误地编译代码，导致看似合理但实际上不正确的结果。（这在 MASS 包中被发现，但从 3.1-57 版本开始已得到解决。）
对于同时支持 64 位和 32 位的平台，很可能
LDFLAGS="-L/usr/local/lib64 -L/usr/local/lib"
是合适的，因为大多数（但并非全部）软件将其 64 位库安装在 /usr/local/lib64 中。为了在 Fedora 34 上构建 ‘x86_64’ 的 32 位版本，我们使用了
CC="gcc -m32"
CXX="g++ -m32"
FC="gfortran -m32"
OBJC=${CC}
LDFLAGS="-L/usr/local/lib"
LIBnn=lib
请注意 ‘LIBnn’ 的使用：‘x86_64’ Fedora 将其 64 位软件安装在 /usr/lib64 中，而 32 位软件安装在 /usr/lib 中。链接将跳过不合适的二进制文件，但例如 32 位 Tcl/Tk 配置脚本位于 /usr/lib 中。可能还需要设置 pkg-config 路径，例如通过
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig
32 位系统 libcurl 无法与系统 CA 证书一起使用：这在 R 的测试套件中得到了解决。
Linux 上的 64 位版本是在支持 > 2Gb 文件的情况下构建的，而 32 位版本（如果可能）也将支持，除非指定了 --disable-largefile。
请注意，一些 32 位 glibc 发行版使用 32 位 time_t 类型，因此要通过所有日期时间检查，需要使用标志 --with-internal-tzcode 构建 R。
使用支持 SSE2 的 ‘ix86’ CPU 的用户80 可能更喜欢使用 C/C++/Fortran 标志
-mfpmath=sse -msse2
强制浮点数使用与 ‘x86_64’ 构建相同的指令，因此不使用 80 位“扩展精度”中间结果。（注意：这影响的不仅仅是浮点运算。对于某些操作系统和版本的 gcc，可能需要添加 -mstackrealign。）
为了在‘ppc64’（也称为‘powerpc64’）上使用 gcc 4.1.1 构建 R 的 64 位版本，Ei-ji Nakama 使用了
CC="gcc -m64" CXX="gxx -m64" FC="gfortran -m64" CFLAGS="-mminimal-toc -fno-optimize-sibling-calls -g -O2" FFLAGS="-mminimal-toc -fno-optimize-sibling-calls -g -O2"
额外的标志是解决与 libnmath.a 链接以及将 R 链接为共享库时遇到的问题。
宏‘SAFE_FFLAGS’ 的设置可能需要一些帮助。除了‘68000’（不太可能遇到）和‘ix86’以外，其他平台不需要额外的标志。对于后者，如果 Fortran 编译器是 GNU（gfortran 或可能是 g77），则添加以下标志
-msse2 -mfpmath=sse
：R 的早期版本添加了 -ffloat-store，如果遇到没有 SSE2 支持的‘ix86’ CPU，可能仍然需要它。请注意，它是‘FFLAGS’的替换，因此应包含该宏中的所有标志（除了可能优化级别）。
可以指定额外的编译标志以进行额外的安全/安全检查。例如，Fedora 将
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Fexceptions -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
添加到所有 C、C++ 和 Fortran 编译器标志中（即使 _GLIBCXX_ASSERTIONS 仅适用于当前 GCC 和 glibc 中的 C++，并且这些标志都没有在 gfortran 中记录）。使用 _GLIBCXX_ASSERTIONS 将链接 abort 和 printf 到几乎所有 C++ 代码中，并且 R CMD check --as-cran 将发出警告。
R 已使用基于 Clang 前端的 Linux ‘ix86’ 和 ‘x86_64’ C 和 C++ 编译器（https://clang.llvm.org）构建，这些编译器由 CC=clang CXX=clang++ 调用，并与 gfortran 一起使用。这些编译器接受与相应的 GCC 编译器非常相似的选项。
这必须与 Fortran 编译器一起使用：configure 代码将从 FLIBS 中删除 -lgcc，这是某些版本的 gfortran 所需的。
目前 clang++ 的默认设置是使用已安装的 g++ 中的 C++ 运行时。使用来自 libc++ 项目（Fedora RPM libcxx-devel）的运行时 通过 -stdlib=libc++ 也已通过测试。
最近的版本（在构建时可选）支持 OpenMP。81
在 Linux 上将 clang 15.0.0 及更高版本作为默认构建以生成 PIE 代码，以及 gfortran 11 或更高版本（不生成 PIE 代码）混合使用时，会出现问题。一个症状是 configure 无法检测到 FC_LEN_T，可以通过设置以下内容来解决
FPIEFLAGS=-fPIE
在 config.site 中。（从 R 4.2.2 开始，configure 会尝试该值，如果它未设置。）
名称 flang 已用于两个项目：这是关于 LLVM 的子项目，它构建了一个 Fortran 编译器和运行时库。该编译器目前名为 flang-new，但已宣布在更接近完成时将重命名为 flang（在其开发的早期阶段被称为 f18）。
LLVM 16 中的版本能够在 ‘x86_64’ Linux 上使用以下命令构建 R
FC=/path/to/flang-new
使用匹配的 clang 作为 C 编译器，并且构建通过了 make check-all。还支持 ‘aarch64’ 和 ‘ppc64le’ Linux，但这些尚未在 R 中测试。
在 2020 年后期，英特尔对其 C/C++ 编译器（以及后来的 Fortran 编译器）进行了改造，以使用 LLVM 后端（对于 C/C++ 编译器，使用修改后的 clang 作为前端）。这些编译器仅适用于 ‘x86_64’：早期的编译器（现在称为 ‘Classic’）还支持 ‘ix86’ 和 ‘x86_64’ 上的 32 位构建。
这些编译器现在都属于英特尔的 ‘oneAPI’ 品牌。改造后的编译器是 icx、icpx 和 ifx；它们通过 C/C++ 宏 __INTEL_LLVM_COMPILER 来识别（并且不定义 __INTEL_COMPILER：它们还定义了 __clang__ 和 __clang_major__）。
C++ 编译器使用系统的 lidstdc++ 作为其运行时库，而不是 LLVM 的 libc++。
独立安装程序（免费）可从 https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html 获取：它们也是 oneAPI Base 和 HPC（针对 Fortran）工具包的一部分。
我们尝试了 oneAPI 2024.0.2 中基于 LLVM 的编译器，使用（路径因编译器版本而异）
IP=/path/to/compilers/bin/ CC=$IP/icx CXX=$IP/icpx FC=$IP/ifx CFLAGS="-O3 -fp-model precise -Wall -Wstrict-prototypes" C17FLAGS="-O3 -fp-model precise -Wall -Wno-strict-prototypes" FFLAGS="-O3 -fp-model precise -warn all,noexternals" FCFLAGS="-free -O3 -fp-model precise -warn all,noexternals" CXXFLAGS="-O3 -fp-model precise -Wall" LDFLAGS="-L/path/to/compilers/compiler/lib -L/usr/local/lib64"
但在检查中（在 tests/lapack.R 中的复杂算术运算中）构建出现了段错误。
英特尔文档构建 R 与 MKL：对于英特尔编译器，这需要类似以下内容
MKL_LIB_PATH=/path/to/intel_mkl/mkl/lib/intel64
export LD_LIBRARY_PATH="$MKL_LIB_PATH"
MKL="-L${MKL_LIB_PATH} -lmkl_intel_lp64 -lmkl_core -lmkl_sequential"
./configure --with-blas="$MKL" --with-lapack
构建在使用 MKL 2023.2.0（但在测试的硬件上不使用 2024.0）时通过了其检查。也可以使用类似 -qmkl=sequential 的编译器选项。
一个怪癖是英特尔 Fortran 编译器不接受 .f95 文件，只接受 .f90 文件，用于自由格式 Fortran。 configure 添加 -Tf，它告诉编译器这确实是一个 Fortran 文件（并且需要紧接文件名之前），但需要 -free 来表示它是自由格式的。因此设置 FCFLAGS 宏。
编译器有很多选项：由于 C/C++ 和 Fortran 编译器的前端来源不同，它们的选项几乎没有一致性。（C/C++ 编译器支持所有 clang 选项，即使 icx/icpc 未记录，例如上面的 -Wno-strict-prototypes。但是，不清楚是哪个版本的 clang：英特尔手册建议检查 icx -help。）C/C++ 编译器支持 clang 风格的 LTO：目前尚不清楚 Fortran 编译器是否支持。
对于某些版本，包括 2023.2.0，除非 src/unix/sys-unix.c 使用 -O0 编译，否则例如 proc.time() 中的所有 CPU 时间都报告为零。
可以使用 -std90、-std95、-std03、-std08 或 -std18（以及变体）设置 ifx 的首选 Fortran 标准。但是，这在文档中仅影响对非标准功能的警告：默认情况下没有此类警告。
对包维护者的警告：英特尔 Fortran 编译器解释为 Visual Fortran82 的注释，例如
!DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'kdenestmlcvb' :: kdenestmlcvb
DLLEXPORT 会发出警告，但其余部分会静默生成命名错误的入口点。此类注释行需要从代码中删除以供 R 使用（即使在 Windows 上使用英特尔 Fortran）。
经典编译器是 icc、icpc 和 ifort。它们由 C/C++ 宏 __INTEL_COMPILER 标识。
经典的 C/C++ 编译器一直可用，直到 2023 年 10 月。版本 2021.10.0（作为 oneAPI 2023.2.0 的一部分发布）在 2023 年 7 月使用
IP=/path/to/compilers/bin/intel64 CC=$IP/icc CXX=$IP/icpc FC=$IP/ifort CFLAGS="-O3 -ip -fp-model precise" FFLAGS="-O3 -fp-model precise" FCFLAGS="-free -O3 -fp-model precise" CXXFLAGS="-O3 -fp-model precise" LDFLAGS="-L/path/to/compilers/compiler/lib/intel64_lin -L/usr/local/lib64"
但除非使用 MKL，否则在检查中也会出现段错误。（CPU 定时在这个编译器上可以正常工作。）
要抑制关于弃用的无休止的警告，请使用
CC="$IP/icc -diag-disable=10441"
icpc 不支持 C++23。
最近只收到过一次关于使用这些编译器的报告：本节的其余部分保留下来，以防它能为在这些编译器仍然可用时使用它们的人提供有用的提示。
Brian Ripley 在 Fedora Core 5 上使用版本 9.0 的编译器为 ‘x86_64’
CC=icc CFLAGS="-g -O3 -wd188 -ip -mp" FC=ifort FLAGS="-g -O3 -mp" CXX=icpc CXXFLAGS="-g -O3 -mp" ICC_LIBS=/opt/compilers/intel/cce/9.1.039/lib IFC_LIBS=/opt/compilers/intel/fce/9.1.033/lib LDFLAGS="-L$ICC_LIBS -L$IFC_LIBS -L/usr/local/lib64" SHLIB_CXXLD=icpc
可能需要使用 CC="icc -std=c99" 或 CC="icc -c99" 来实现 C99 兼容性。标志 -wd188 会抑制大量关于枚举类型 ‘Rboolean’ 的警告。由于 Intel C 编译器会设置 ‘__GNUC__’ 但不会完全模拟 gcc，因此建议添加 CPPFLAGS=-no-gcc。
为了保持正确的 IEC 60559 算术，您很可能需要向 CFLAGS、FFLAGS 和 CXXFLAGS 添加标志，例如 -mp（如上所示）或 -fp-model precise -fp-model source，具体取决于编译器版本。
其他人报告了使用版本 10.x 和 11.x 的成功案例。Bjørn-Helge Mevik 报告了使用版本 2015.3 的编译器取得成功的案例，使用（针对 Centos 6.x 上的 SandyBridge CPU）
fast="-fp-model precise -ip -O3 -opt-mem-layout-trans=3 -xHost -mavx" CC=icc CFLAGS="$fast -wd188" FC=ifort FFLAGS="$fast" CXX=icpc CXXFLAGS="$fast"
32 位构建可能需要强制在 SAFE_FFLAGS 中使用 SSE2 指令，例如通过
SAFE_FFLAGS=-axsse2
此处的说明适用于 macOS 11（Big Sur）、12（Monterey）和 13（Ventura）上的 Intel 64 位 (‘x86_64’) 或 ‘Apple Silicon’ (‘arm64’) 构建。（它们可能在 Intel macOS 10.14 或 10.15 上也能正常工作，但尚未在那里测试。）
Intel 组件安装到 /opt/R/x86_64，Apple 硅组件安装到 /opt/R/arm64。这可能不存在83，因此最简单的方法是首先创建目录并在需要时调整其所有权：例如通过
sudo mkdir -p /opt/R/arm64 sudo chown -R $USER /opt/R
此外，将 /opt/R/x86_64/bin 或 /opt/R/arm64/bin 添加到您的路径。
在您的终端中定义一个适当的变量
set LOCAL=/opt/R/x86_64 # Intel set LOCAL=/opt/R/arm64 # Apple Silicon
以使用此处的代码片段。
以下内容对于构建 R 至关重要
xcode-select --install 来（重新）安装。
如果您有一个全新的操作系统安装，例如在终端中运行 make 将提供命令行工具的安装。如果您已安装 Xcode，则它将提供命令行工具。在 macOS 升级时可能需要重新安装这些工具，因为升级可能会部分或完全删除它们。
命令行工具提供从 LLVM 的 clang 派生的 C 和 C++ 编译器，但如今被称为“Apple clang”，具有不同的版本控制（因此 Apple clang 14 与 LLVM clang 14 无关）。
pcre284 和 xz（用于 liblzma）。那里有一个 R 脚本可以帮助安装所有需要的组件。（在撰写本文时，install.libs("r-base-dev") 既没有安装 readline5，也没有安装支持 Pango 所需的组件。）
Intel 用户需要 darwin20 组件：darwin17 组件适用于 macOS 10.13–10.15。
或者，这可以通过以下方式手动完成
curl -OL https://mac.r-project.org/bin/darwin20/x86_64/pcre2-10.42-darwin.20-x86_64.tar.xz sudo tar -xvzf pcre2-10.42-darwin.20-x86_64.tar.gz -C / curl -OL https://mac.r-project.org/bin/darwin20/x86_64/xz-5.4.2-darwin.20-x86_64.tar.xz sudo tar -xvzf xz-5.4.2-darwin.20-x86_64.tar.xz -C /
（如果您的帐户拥有 /opt/R/x86_64 或 /opt/R/arm64，则不需要 sudo。）
应忽略类似“opt/R/: Can't restore time”的消息。
以及理想的
readline5。85 如果没有 readline，将使用 Apple 版 libedit（也称为 editline）中的模拟：如果您希望避免这种情况，请使用 --without-readline 进行配置。
jpeg、libpng、pkgconfig、tiff 和 zlib-system-stub 来自 https://mac.r-project.org/bin//，用于全面的位图图形设备。（某些版本的 tiff 可能需要 libwebp 和/或 openjpeg。）
configure 脚本可以被告知在 XQuartz 的主要位置 /opt/X11 中查找 X11，例如通过
--x-includes=/opt/X11/include --x-libraries=/opt/X11/lib
请注意 XQuartz 的预发布版本，这些版本可能会作为更新提供。
clang 提供：这对于 quartz() 图形设备是必需的。
如果您想要一个标准的类 Unix 构建，请使用 --without-aqua：除了禁用 quartz() 和使用构建与 R.APP 的能力之外，它还会更改个人库的默认位置（请参阅 ?.libPaths）。
texi2any 来自 “texinfo” 发行版，它需要 perl（目前是 macOS 的默认部分，但已宣布它可能不会出现在未来版本中）。texi2any 的一个版本已包含在 R 的二进制发行版中，并且在 https://mac.r-project.org/bin/ 中有一个 texinfo 组件。
要使用命令行工具（或 Xcode）中的 C/C++ 编译器和下面提到的安装程序中的 gfortran 从源代码构建 R 本身，请使用包含以下内容的文件 config.site：
CC=clang OBJC=$CC FC="/opt/gfortran/bin/gfortran -mtune=native" CPPFLAGS='-isystem $LOCAL/include' CXX=clang++
并通过类似以下内容进行配置：
./configure -C \ --enable-R-shlib --enable-memory-profiling \ --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib \ --with-tcl-config=$LOCAL/lib/tclConfig.sh \ --with-tk-config=$LOCAL/lib/tkConfig.sh \ PKG_CONFIG_PATH=$LOCAL/lib/pkgconfig:/usr/lib/pkgconfig
（有关 Tcl/Tk 的其他选项，请参见下文。）对于“arm64”构建，在 config.site 中需要更多标志：
CFLAGS="-falign-functions=8 -g -O2" FFLAGS="-g -O2 -mmacos-version-min=11.0" FCFLAGS="-g -O2 -mmacos-version-min=11.0"
（CFLAGS 中的第一个标志是与 gfortran 协同工作所必需的，以防止某些包中出现段错误，并且某些 gfortran 版本已针对当前版本的 macOS（与 clang 不同，会导致链接器警告）。
要使用已编译的代码安装包，需要命令行工具（或 Xcode）和相应的编译器，例如这些工具中的 C/C++ 编译器和/或 gfortran。某些包还有其他要求，例如组件 pkgconfig（以及设置 PKG_CONFIG_PATH=，如上所述）。
可以从 https://mac.r-project.org/tools/ 获取 Subversion 客户端，例如通过：
curl -OL https://mac.r-project.org/tools/subversion-1.14.0-darwin15.6.tar.gz tar xf subversion-1.14.0-darwin15.6.tar.gz sudo cp subversion-1.14.0-darwin15.6/svn $LOCAL/bin
（该网页上还有一个 arm64 版本。）
如果使用 cmake（或非 Apple make）为“Apple Silicon”构建软件或安装源代码包，请确保它包含“arm64”架构（使用 file 确保）。从“x86_64”可执行文件运行 Apple 编译器将生成“x86_64”代码……
更新“arm64”构建可能会失败，因为 https://openradar.appspot.com/FB8914243 中描述的错误，但 ab initio 构建可以正常工作。自 macOS 13 以来，这种情况已变得非常罕见。
如果您使用的是 macOS 13 SDK86，您可能需要在“CFLAGS”中添加类似 -mmacos-version-min=12.0 的内容。
可以忽略类似以下内容的链接器警告：
ld: warning: could not create compact unwind for _sort_: register 26 saved somewhere other than in frame ld: warning: ld: warning: could not create compact unwind for _arcoef_: registers 23 and 24 not saved contiguously in frame ld: warning: could not create compact unwind for ___emutls_get_address: registers 23 and 24 not saved contiguously in frame
这些警告源于已编译的 Fortran 代码，包括其运行时库。
默认的安全设置可能会使安装未经 Apple “公证”87 的 Apple 软件包变得困难。不仅是软件包，因为在 tarball/zip 文件（例如，pandoc）中包含的可执行文件也观察到了这种情况。通常可以使用“打开方式”（在 Finder 中使用 Control/右键/双指点击），然后选择“安装程序”和“打开”，如果您收到进一步的警告消息。
如果您在浏览器中下载的 tarball 遇到“隔离”问题，请考虑使用 curl -OL 下载（如上所示）或 xattr -c 删除扩展属性。
configure 在 macOS 上默认设置为 --with-internal-tzcode。以前版本的原生实现是不可用的（使用 32 位 time_t 和/或时区表缺少超过 32 位范围的信息）。例如，对于 macOS 12.6，可以使用选项 --without-internal-tzcode 来覆盖此设置，并且 R 包含足够的解决方法（例如，原生代码无法识别具有负 tm_year 的日期，即 1900 年之前的日期）以使 R 通过其检查。但是，存在差异，尤其是在 1900 年代和 1940 年代的欧洲，即使 Olson 数据库包含正确的信息。
在 https://mac.r-project.org/tools/gfortran-12.2-universal.pkg 上有一个“通用”（Intel 和 arm64）版本的 gfortran 12.2。它安装到 /opt/gfortran 中。
符号链接 /opt/gfortran/SDK 应该指向所需的 SDK 路径（默认指向命令行工具 SDK）。可以通过运行 /opt/gfortran/bin/gfortran-update-sdk 或手动更新。如果符号链接已损坏，驱动程序将发出警告并使用 xcrun -show-sdk-path 尝试查找 SDK 并使用其路径。（SDK 路径在使用 gfortran 进行链接时使用，因此不是在构建 R 时使用，而是在安装一些包时使用。）
基于 Cairo 的图形设备，例如 cairo_ps、cairo_pdf、X11(type = "cairo") 以及基于 Cairo 的设备类型 bmp jpeg、png 和 tiff，在 macOS 上并非默认设备，使用频率也远低于基于 Quartz 的设备。然而，R 发行版中唯一的 SVG 设备 svg 是基于 Cairo 的。
对 Cairo 的支持是可选的，可以通过多种方式添加，所有方式都需要 pkg-config。如果 pkg-config 找到包 cairo，configure 将添加 Cairo 支持，除非使用 --without-cairo。
一种静态链接 Cairo 的方法是下载并解压组件 cairo、fontconfig、freetype、pixman 和 zlib-system-stub（并且不要在 PKG_CONFIG_PATH 中包含 /opt/X11/lib/pkgconfig）。一些 fontconfig 的静态构建需要 libxml2（来自组件 xml2），而其他构建需要 expat，macOS 提供了 expat，但需要一个类似于以下内容的文件 $LOCAL/lib/pkgconfig/expat.pc：
Name: expat Version: 2.2.8 Description: expat XML parser URL: http://www.libexpat.org Libs: -lexpat Cflags:
请注意，组件列表可能会发生变化：运行 pkg-config cairo --exists --print-errors 可以告诉你是否需要其他组件。
Cairo 图形最佳的字体体验是与 Pango 结合使用，这将与大多数其他类 Unix 系统上支持的字体相匹配。 configure 使用 pkg-config 来确定 Pango 和 Cairo 所需的所有外部软件是否可用：运行 pkg-config pangocairo --exists --print-errors 可以显示安装是否足够，如果不足，则显示缺少什么。在撰写本文时，使用预构建组件 cairo、fontconfig、freetype、ffi、fribidi、gettext、icu、glib、harfbuzz、pango、pcre、pixman 和 xml2 就足够了。
其他版本的 clang 可以从 https://github.com/llvm/llvm-project/releases/ 获取（最近仅适用于 arm64，通常未签名/未经公证，这使得它们难以使用）。特别是，这些版本包括对 OpenMP 的支持，而 Apple clang 则没有。其中一些版本还包括对 ASAN 和 UBSAN 净化器的支持。
假设其中一个版本安装在 $LOCAL/llvm 下。使用包含以下内容的文件 config.site：
CC="$LOCAL/llvm/bin/clang -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" CXX="$LOCAL/llvm/bin/clang++ -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" OBJC=$CC FC=$LOCAL/gfortran/bin/gfortran LDFLAGS="-L$LOCAL/llvm/lib -L$LOCAL/lib" R_LD_LIBRARY_PATH=$LOCAL/llvm/lib:$LOCAL/lib
如果 SDK 的位置发生变化（或者 Xcode 提供 SDK 而不是命令行工具），可以通过运行 xcrun -show-sdk-path 来找到它。
指定库路径的目的是确保在需要时找到 OpenMP 运行时库，这里为 $LOCAL/llvm/lib/libomp.dylib。如果这有效，你应该在 configure 输出中看到以下行：
checking whether OpenMP SIMD reduction is supported... yes
此外，需要设置 ‘R_LD_LIBRARY_PATH’ 以找到最新版本的 C++ 运行时库，而不是系统库。
通常可以使用 GCC 构建 R（从源代码构建，从 gfortran 发行版构建，从 Homebrew 构建，…）。在上次测试时88，无法使用 gcc 构建 quartz() 设备，因此可能需要使用 configure --without-aqua。
通常可以为 Apple clang 编译器添加一些 OpenMP 支持：请参阅 https://mac.r-project.org/openmp/。请注意，这种方法有些脆弱，因为它需要一个与所用编译器版本匹配的 libomp.dylib 库——例如，在撰写本文时，没有为 Xcode/CLT 14.3 或 15 中的当前编译器提供任何库。
许多 有用库和程序 的预编译版本可从 https://mac.r-project.org/bin// 获取。
Accelerate 库89 可以通过配置选项使用
--with-blas="-framework Accelerate"
来提供 BLAS 和 LAPACK 例程的潜在更高性能版本。90 这也包括一个完整的 LAPACK，可以通过 --with-lapack 使用：但是，它包含的 LAPACK 版本通常非常旧（并且除非指定了 --with-lapack，否则不会使用）。一些 CRAN 构建的 R 可以切换91 以使用 Accelerate 的 BLAS。
对 macOS 13.3 及更高版本中 Accelerate 版本的支持已添加到 R 4.4.0 中。
Accelerate 中的线程由“Grand Central Dispatch”92 控制，据说不需要用户控制。在 Intel macOS 上，使用 Accelerate BLAS 时，包 stats 中的测试文件 nls.R 经常会失败。
查看 /Library/Frameworks/R.framework/Resources/etc/Makeconf 的顶部将显示用于 R 的 CRAN 二进制包的编译器和配置选项：在撰写本文时，非默认选项
--enable-memory-profiling --enable-R-framework --x-libraries=/opt/X11/lib --x-includes=/opt/X11/include
被使用。（--enable-R-framework 意味着 --enable-R-shlib。）
开发人员使用的主要 TeX 实现是 MacTeX93 (https://www.tug.org/mactex/)：完整安装大约 8.5GB，但可以在 https://www.tug.org/mactex/morepackages.html 获取更小的版本（“基本 TeX”），您需要添加一些包才能构建 R，例如，对于 2022 版本，我们需要添加94 helvetic、inconsolata 和 texinfo，这将使大小达到约 310MB。95 “TeX Live Utility”（可通过 MacTeX 首页获得）提供了一种图形化方式来管理 TeX 包。这些包包含在“x86_64”和“arm64”上本地运行的可执行文件。
彻底检查包需要 ghostscript（完整 MacTeX 发行版的一部分或单独从 https://www.tug.org/mactex/morepackages.html 获取）和 qpdf（从 https://mac.r-project.org/bin// 获取，R 二进制安装的 bin 目录中有一个版本，通常为 /Library/Frameworks/R.framework/Resources/bin/qpdf）。
R CMD check --as-cran 使用“HTML Tidy”。macOS 在 /usr/bin/tidy 中有一个来自 2006 年的版本，该版本过于陈旧，因此会被跳过。可以从 http://binaries.html-tidy.org/ 安装最新版本。
macOS 的一个怪癖是，默认路径在 /usr/bin 之后是 /usr/local/bin，这与类 Unix 系统的常见做法相反。这意味着，如果您从源代码安装工具，它们默认情况下将安装在 /usr/local 下，而不是取代系统版本。
如果可用，包的并行安装将使用实用程序 timeout。可以从 https://www.stats.ox.ac.uk/pub/bdr/timeout 下载双架构构建：使其可执行 (chmod 755 timeout) 并将其放在您的路径上的某个位置。
如果您计划使用 R 的 tcltk 包，您需要安装 Tcl/Tk 的发行版。有两种选择。如果您使用 R.APP，您将需要使用基于 X11 的 Tcl/Tk（如在其他类 Unix 系统上使用），它作为 R 的 CRAN 二进制文件的一部分安装在 $LOCAL/lib 下。 96 这可能需要 configure 选项
--with-tcltk=$LOCAL/lib
或
--with-tcl-config=$LOCAL/lib/tclConfig.sh --with-tk-config=$LOCAL/lib/tkConfig.sh
请注意，这需要匹配的 XQuartz 安装。
还有一个本机（“Aqua”）版本的 Tcl/Tk，它以 macOS 本机样式生成小部件：这将无法与 R.APP 一起使用，因为 macOS 菜单存在冲突，但对于那些只使用命令行 R 的用户来说，这为经验丰富的 Mac 用户提供了更直观的 Tk 接口。早期的 macOS 版本附带了 Aqua Tcl/Tk 发行版，但这些版本通常不是最新的 Tcl/Tk 版本。最好从源代码安装 Tcl/Tk 8.6.x 97 或从 https://www.activestate.com/products/tcl/ 安装二进制发行版。对于后者，使用以下命令配置 R：
--with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh --with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh
如果您需要在运行时找出正在使用的 Tk 发行版，请使用
library(tcltk)
tclvalue(.Tcl("tk windowingsystem")) # "x11" or "aqua"
请注意，一些 Tcl/Tk 扩展只支持 X11 接口：这包括 Tktable 和 CRAN 包 tkrplot。
macOS 不附带已安装的 Java 运行时 (JRE)，macOS 升级可能会删除已安装的 Java 运行时：它旨在在首次使用时安装。通过在 Terminal 窗口中运行 java -version 来检查是否安装了 JRE：如果 Java 未安装 98，这将提示您安装它。 99 OpenJDK 的构建也可能可用，例如来自 Adoptium、Azul 或 https://jdk.java.net/。我们建议您安装具有长期支持的版本，例如 11 或 17 或（预计在 2023-09）21，但不要安装 12–16 或 18–20，这些版本具有/曾经具有 6 个月的生命周期。（请注意，这些来源可能对 Intel macOS 构建使用不寻常的名称，例如 x86 64-bit 和 x64。）
R 的二进制发行版针对特定版本的 Java（例如 11.0.6 或 17.0.1）构建，因此在使用使用 Java 的包之前，可能需要运行 sudo R CMD javareconf。
要查看当前安装了哪些兼容版本的 Java，请运行以下命令之一：
/usr/libexec/java_home -V -a x86_64 /usr/libexec/java_home -V -a arm64
如果需要，请设置环境变量 JAVA_HOME 以在从源代码构建 R 和运行 R CMD javareconf 时在这两者之间进行选择。
配置和构建 R 都在寻找 JRE 和编译 JNI 程序（用于安装包 rJava 和 JavaGD）的支持；后者需要 JDK（Java SDK）。大多数 Java 9 或更高版本的发布版都是完整的 JDK。
构建过程试图弄清楚要使用哪个 JRE/JDK，但它可能需要一些帮助，例如通过设置环境变量 JAVA_HOME。要从 Adoptium 选择一个构建，请设置例如：
JAVA_HOME=/Library/Java/JavaVirtualMachines/termurin-17.jdk/Contents/Home
在 config.site 中。对于来自 https://jdk.java.net/ 的 Java 17（已不再可用），请使用：
JAVA_HOME=/path/to/jdk-17.jdk/Contents/Home
对于“arm64”构建，官方支持的 Java 最早版本是 17。目前安装 Java 最简单的方法是从 Adoptium（他们将架构称为“aarch64”）：这会安装到 Apple 标准位置，因此可以使用 /usr/bin/java。其他构建可从 https://www.azul.com/downloads/zulu-community/?os=macos&architecture=arm-64-bit&package=jdk 和 OpenJDK 的 https://jdk.java.net/ 获取，对于这些构建，可能需要在配置 R 和运行时都设置 JAVA_HOME。
要在“arm64”macOS 上使用 Java（特别是二进制包 rJava）与 CRAN（“x86_64”）的 R 二进制发行版一起使用，请从上面链接的站点之一安装 Intel 版本的 Java JRE，然后运行 sudo R CMD javareconf。
请注意，有必要将环境变量 NOAWT 设置为 1 才能安装许多使用 Java 的包。
R 的 CRAN 构建被安装为一个框架，它由以下选项选择：
./configure --enable-R-framework
(这旨在与 Apple 工具链一起使用：其他工具链可能不支持框架，但 LLVM 的工具链除外。)
只有在您想构建用于 R.APP 控制台的 R 时才需要它，并且意味着 --enable-R-shlib 将 R 构建为动态库。此选项将 R 配置为构建并安装为名为 R.framework 的框架。 R.framework 的默认安装路径是 /Library/Frameworks，但这可以通过在配置时指定标志 --enable-R-framework[=DIR]（或 --prefix）或在安装时通过 via 来更改。
make prefix=/where/you/want/R.framework/to/go install
请注意，作为框架安装是非标准的（尤其是安装到非标准位置），并且 Unix 实用程序可能不支持它（例如，pkg-config 文件 libR.pc 将被放置在 pkg-config 未知的位置）。
构建 R.APP GUI 控制台是一个独立的项目，使用 Xcode。在编译 R.APP 之前，请确保当前版本的 R 已安装在 /Library/Frameworks/R.framework 中，并且在命令行中可以正常工作（这可以是二进制安装）。
可以通过以下方式签出当前源代码：
svn co https://svn.r-project.org/R-packages/trunk/Mac-GUI
并通过加载 R.xcodeproj 项目（选择 R 目标和合适的配置）进行构建，或者从命令行通过以下方式进行构建：
xcodebuild -target R -configuration Release
另请参阅签出中的 INSTALL 文件，或直接访问 https://svn.r-project.org/R-packages/trunk/Mac-GUI/INSTALL。
R.APP 不需要以任何特定方式安装。构建 R.APP 会生成 R.APP 包，它显示为一个 R 图标。此应用程序包可以在任何地方运行，通常将其放置在 /Applications 文件夹中。
CRAN macOS 二进制包以带有 .tgz 后缀的 tarball 形式分发，以将其与源代码 tarball 区分开来。您可以 tar 一个现有的已安装包，或者使用 R CMD INSTALL --build。
但是，有一些重要的细节。
CC="clang -mmacosx-version-min=11.0" CXX="clang++ -mmacosx-version-min=11.0" FC="/opt//gfortran/bin/gfortran -mmacosx-version-min=11.0"
或设置环境变量
export MACOSX_DEPLOYMENT_TARGET=11.0
otool -L 或 objdump -macho -dylibs-used。这可能包括 /opt/R/x86_64/lib 或 /opt/R/arm64/lib 下的 C++ 和 Fortran 运行时库：可以使用 install_name_tool 将它们指向系统版本或与 R 一起提供的版本，例如
install_name_tool -change /usr/local/llvm/lib/libc++.1.dylib \ /usr/lib/libc++.1.dylib \ pkg.so install_name_tool -change /opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/12.2.0/libgfortran.5.dylib \ /Library/Frameworks/R.framework/Resources/lib/libgfortran.5.dylib \ pkg.so install_name_tool -change /opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/12.2.0/libquadmath.0.dylib \ /Library/Frameworks/R.framework/Resources/lib/libquadmath.0.dylib \ pkg.so
（其中详细信息取决于编译器和 CRAN macOS R 版本）。
SHLIB_CXXLD = /usr/local/llvm/bin/clang PKG_LIBS = /usr/local/llvm/lib/libc++.a /usr/local/llvm/lib/libc++abi.a
在 src/Makevars 中。也可以静态链接 Fortran 运行时库 libgfortran.a 和 libquadmath.a，如果 Fortran 编译器有更高版本（但 gfortran 8-13 都有版本 5）。
在支持的 macOS 最旧版本上使用 Apple 编译器构建 CRAN 二进制包，这避免了前两个问题以及与 C++ 库相关的任何问题。
如果想要在 ‘arm64’ Big Sur Mac 上为 Intel 构建 R，请为 C 和 C++ 编译器添加目标
CC="clang -arch x86_64 OBJC=$CC CXX="clang++ -arch x86_64" FC="/opt//gfortran/bin/gfortran -arch x86_64 -mtune=native -mmacosx-version-min=11"
并安装上面为 Intel 构建描述的 Fortran 编译器和外部软件（并将 /opt/R/x86_64/bin 放在 /opt/R/arm64/bin 之前）。
要设置正确的体系结构（将自动检测为 aarch64），请使用类似以下内容：
/path/to/configure --build=x86_64-apple-darwin20
R 的 CRAN 打包脚本可以在 https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4/ 下找到：从该目录中的 README 文件开始。
FreeBSD 上的 R 近期鲜有报道：在 https://svnweb.freebsd.org/ports/head/math/R 上有一个“port”，目前最新更新至 R 4.0.4。最近版本的 FreeBSD 使用 Clang 和 libc++ C++ 头文件和运行时，但“port”已配置为使用 GCC。
使用 ICU 进行排序和 configure 选项 --with-internal-tzcode 是可取的解决方法。
Ingo Feinerer 在 OpenBSD 5.8 架构“amd64”（他们对“x86_64”的称呼）上安装了 R 版本 3.2.2。构建的详细信息（以及应用的补丁）位于 https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/math/R/，目前最新更新至 R 4.2.1。
在新的硬件/操作系统平台上安装 R 时，存在许多问题来源。这些包括
浮点运算: R 要求符合 IEC 60559 标准的算术运算，也称为 IEEE 754 标准。该标准规定了使用正负无穷大和 NaN（非数字）以及舍入的具体细节。虽然几乎所有当前的浮点运算单元 (FPU) 都能支持此标准，但选择这种支持可能很麻烦。问题在于，关于如何设置信号行为没有达成一致；Sun/Sparc、SGI/IRIX 和 ‘ix86’ Linux 不需要任何特殊操作，FreeBSD 需要调用 (宏) fpsetmask(0)，而 OSF1 则要求使用 -ieee_with_inexact 标志进行计算等等。在 32 位和 64 位英特尔机器上的英特尔编译器中，必须显式禁用 flush-to-zero 和 denormals-are-zero 模式。一些 ARM 处理器，包括 A12Z 和 M1（苹果硅），默认使用 runfast 模式，其中包括 flush-to-zero 和 default-nan，因此必须禁用。在 default-nan 模式下，用于表示数值 NA 值的 NaN 负载即使在对有限值的简单操作中也会丢失。在新的平台上，您必须找到神奇的配方并添加一些代码才能使其工作。这通常可以通过位于顶层目录中的 config.site 文件来完成。
注意使用高水平的优化，至少在最初阶段。在许多编译器中，这些优化会降低对 IEEE 模型的符合程度。例如，在 Oracle 编译器中使用 -fast 会导致 R 的 NaN 设置不正确，而 gcc 的 -ffast-math 和 clang 的 -Ofast 会给出错误的结果。
共享对象: 在不同平台上，关于构建共享对象需要做些什么似乎没有达成一致。编译器和加载器有许多不同的标志组合。GNU libtool 无法使用（目前），因为它目前不支持 Fortran：这需要一个 shell 包装器。我们使用的技术是首先询问 X 窗口系统它做了什么（使用 xmkmf），然后在知道更好的情况下覆盖它（对于来自 GNU 编译器集合的工具和/或我们知道的平台）。这通常有效，但您可能需要手动覆盖结果。扫描 cc 和 ld 的手册条目通常会显示正确的咒语。一旦您知道配方，就可以修改 config.site 文件（按照其中的说明），以便构建将使用这些选项。
看起来 gcc 3.4.x 及更高版本在 ‘ix86’ Linux 上会阻止 LAPACK 代码完全在扩展精度寄存器中进行计算，因此文件 src/modules/lapack/dlamc.f 可能需要在没有优化的情况下编译，或者使用额外的标志。将配置变量 SAFE_FFLAGS 设置为要用于此文件的标志。
如果您成功地在新的平台上运行 R，请告知我们，以便我们修改配置过程以包含该平台。
如果您在您的平台上运行 R 时遇到问题，请随时使用 ‘R-devel’ 邮件列表提问。我们已经积累了相当多的将 R 移植到新平台的经验 ...
对于新平台，您可能需要添加的一件事是将 C/C++/Fortran 调用映射到用于 R CMD check 的入口点名称。请查看 https://svn.r-project.org/R-dev-web/trunk/sotools.txt 了解如何操作。
| 跳转到： | C I M R U |
|---|
| 索引条目 | 章节 | |
|---|---|---|
| C | ||
configure | 简单编译 | |
configure | 简单编译 | |
configure | 安装 | |
configure | 安装 | |
configure | 配置变量 | |
configure | 使用 make | |
| I | ||
install.packages | 安装包 | |
| M | ||
make | 使用 make | |
| R | ||
R_HOME | 简单编译 | |
remove.packages | 删除包 | |
| U | ||
update.packages | 更新包 | |
| 跳转到： | C I M R U |
|---|
| 跳转到： | B C F I L M O P R S U V |
|---|
| 跳转到： | B C F I L M O P R S U V |
|---|
| 跳转到： | B C D J L P R T |
|---|
| 跳转到： | B C D J L P R T |
|---|
例如，GNU tar 版本 1.15 或更高版本，或来自 ‘libarchive’（如 macOS 上使用）或 ‘Heirloom Toolchest’ 发行版。
对于某些 Subversion 客户端，‘http:’ 似乎可以工作，但需要持续重定向。
也称为 ‘Apple Silicon’，有些人称之为 ‘arm64-apple-darwin’。
在 R 4.3.0 之前，空格是被不鼓励但允许的。
使用 lib 而不是 lib64 作为其主要 64 位库目录：尝试检测此类系统。
不是由 macOS 提供的版本。
有关如何安装最新版本的说明，请访问 https://www.ctan.org/tex-archive/fonts/inconsolata/。
在类 Unix 系统上，如果 configure 未找到，则省略 “inconsolata”。
如果要安装多个子体系结构，则需要这样做。
可能的值为 “i386”、“x64”、“32” 和 “64”。
主要是在 RedHat 和 Fedora 上，其布局在此处描述。
有关如何准备此类目录的说明，请参阅 R 源代码中的 src/extra/tzone/Notes 文件。
但在 Windows 上，在带重音的拉丁字母 1 字符上使用大小写转换函数时，会出现问题。
例如，-fopenmp、-fiopenmp、-xopenmp 或 -qopenmp。这包括 clang 以及 Intel 和 Oracle 编译器。
这并不一定禁用 OpenMP 的 使用 - configure 代码允许在没有标志的情况下使用 OpenMP 的平台。对于 2017 年底的 flang 编译器，Fortran 运行时始终使用 OpenMP。
然后，作为 R 安装的一部分安装的推荐包使用 LTO，但后来安装的包则不使用。
完整的 CRAN 安装从 50 GB 减少到 35 GB。
虽然可以选择排除 Fortran，但这会错过一些好处。
不是 NM，因为我们发现 make 覆盖了它。
可能还有 8.4 及更高版本。
有报告称，在制作 NEWS.pdf 时，当 “MiKTeX” 安装附加包时，会出现段错误：重新运行 make 似乎可以解决此问题。
您可能需要在首次使用时安装 Rosetta - https://support.apple.com/en-us/HT211861 - 这可能需要管理员权限。
截至撰写本文时，版本为 2.8.5 或更高版本。
安装程序将 R 和 Rscript 的链接放在 /usr/local/bin 中。如果这些链接丢失或不在您的路径中，您可以直接运行 /Library/Frameworks/R.framework/Resources/bin 中的副本，或者将它们链接到您路径中的某个位置。
截至撰写本文时：使用 pkgutil --pkgs | grep -i org.r-project 检查。
更准确地说，是同名 Apple 包：这意味着 Intel 和 ARM 版本可以一起安装。
包括 Linux 上的 GCC 9。
在 Windows 上，如果包含空格的路径不包含空格，则该路径将被替换为“短路径”版本。
除非它们在构建中被排除在外。
它的绑定在读取启动文件后被锁定，因此用户无法轻松更改它。有关如何使用新值的说明，请参见 ?.libPaths。
如果需要设置代理，请参见 ?download.file。
对于少数已知安全的 CRAN 包，并且自动构建器需要这些包，这是默认设置。查看 tools:::.install_packages 的源代码以获取列表。它也可以在包的 DESCRIPTION 文件中指定。
请注意，大小写和版本控制可能与开源项目不同。
从 Big Sur 开始，这些库对公众不可见：系统编译器链接到“基于文本的定义”（.tbd）文件。
使用包含空格的路径可能会导致问题。
它们需要使用 -headerpad_max_install_names 创建，这是 R 包的默认设置。
“X/Open 可移植性指南”，该指南已发布多个版本。
在某些系统上，将 LC_ALL 或 LC_MESSAGES 设置为“C”会禁用 LANGUAGE。
如果您尝试从法语更改为俄语，但不在 UTF-8 本地化中，您可能会发现消息更改为英语。
在英国使用的语言：一些居住在美国的人将此名称用于他们的语言。
带有美国英语。
也称为 IEEE 754
至少在存储数量时：允许 FPU 上的精度变化。
例如贝塞尔、贝塔和伽马函数。
包括将 MkRules.dist 复制到 MkRule.local 并选择体系结构。
也称为 IEEE 754
请注意，C11 编译器不必兼容 C99：R 需要支持 double complex 和可变长度数组，它们在 C11 中是可选的，但在 C99 中是强制性的。C17（也称为 C18，因为它是在 2018 年发布的）是 C11 的“错误修复版本”，它澄清了标准。但是，所有已知的最新 C11 或 C17 模式编译器都兼容 C99，并且大多数默认使用 C17。
例如 -std=gnu99、-std=c99 和 -c99。
但是，可以通过重新指定要加载的 gconv 模块来破坏 glibc 的默认行为。
具体来说，是 wchar.h 和 wctype.h 头文件中的 C99 功能，wctans_t 和 mbstate_t 类型以及 mbrtowc、mbstowcs、wcrtomb、wcscoll、wcstombs、wctrans、wctype 和 iswctype 函数。
包括 expm1、hypot、log1p、nearbyint 和 va_copy。
包括 opendir、readdir、closedir、popen、stat、glob、access、getcwd 和 chdir 系统调用，在类 Unix 系统上使用 select，以及 putenv 或 setenv。
例如 realpath、symlink。
通常作为 xz 的一部分进行分发：在 Linux 发行版中可能使用的名称包括 xz-devel/xz-libs 和 liblzma-dev。
例如，要指定使用同时包含共享库和静态库的构建进行静态链接。
例如 GNU tar 1.15 或更高版本、bsdtar（来自 https://github.com/libarchive/libarchive/，在 FreeBSD 和 macOS 10.6 及更高版本中用作 tar）或 Heirloom Toolchest 中的 tar (https://heirloom.sourceforge.net/tools.html)，尽管后者不支持 xz 压缩。
texi2dvi 通常是一个 shell 脚本。通过将环境变量 R_TEXI2DVICMD 设置为 emulation 值，可以规避在损坏的 texi2dvi 版本中观察到的某些问题。
如果需要，可以通过在 config.site 中设置 PKG_CONFIG 环境变量，在 configure 命令行中设置，或在环境中设置来指定 pkg-config 的路径。如果 pkg-config 已安装但未链接到 pkg-config，则可以使用名为 pkgconf 的兼容重新实现。
在 Debian/Ubuntu 中也称为 ttf-mscorefonts-installer：另请参见 https://en.wikipedia.org/wiki/Core_fonts_for_the_Web。
ttf-liberation 在 Debian/Ubuntu 中。
包括 Fedora 使用的。
R 使用 rpc/xdr.h，但它包含来自顶级 tirpc 目录的 netconfig.h。
即使在 macOS 上的“Aqua”版本的 Tk 中也是如此，但该版本的发布版包含了所需的 X11 文件副本。
当前的搜索顺序是 OpenBLAS、BLIS、ATLAS、特定于平台的选择（见下文），最后是通用的 libblas。
使用 Oracle Developer Studio cc 和 f95 编译器
要查看已针对哪些 CPU 优化了分布式库，唯一的方法是阅读 atlas.spec 文件。
https://math-atlas.sourceforge.net/atlas_install/
https://math-atlas.sourceforge.net/faq.html#tnum
（以及更多，例如 64 位整数和静态版本）。
如今被称为“英特尔 oneAPI 数学内核库”或“oneMKL”。
macOS 的问题一直是使用双复数例程。
ATLAS、OpenBLAS 和 Accelerate。
我们在“i686”Linux 上测量了 15-20%，在“x86_64”Linux 上测量了 10% 左右。
我们认为 3.4.0 到 3.19.0 版本是兼容的。
在 2021 年底修订本段时，autoconf-2.71 和 automake-1.16.5。随后测试了 autoconf-2.72。
那里的链接很难访问，在这种情况下，请获取在 https://developer.r-project.org/noweb-2.11b.tgz 中提供的副本。
大多数基于 clang 的编译器给出 4，但 FreeBSD 分发的编译器除外。英特尔的 icx 在 2023 年报告了 12。
例如，无法加载大小为 14 的 X11 字体。
例如，glibc：其他 C 库，如 musl（Alpine Linux 使用）已被使用，但没有经过常规测试。
可能所有从 2005 年开始的，包括奔腾 4 和所有使用 32 位编译器的“x86_64”CPU。
这还需要 OpenMP 运行时，有时它会单独分发。
正如编译器在 Windows 上所知。
如果 R 是从 R 4.3.0 开始从 CRAN 安装的，它将。
如果从源代码在 ‘arm64’ 上编译，pcre2（至少到 10.39 版本）需要在没有 JIT 支持的情况下构建（默认情况下），因为如果启用了 JIT 支持，R 构建会发生段错误，因此请在您的构建上运行 make check。
出于许可原因，这是 readline 的 5.2 版本：对于那些想要更新版本的人来说，从其源代码编译它很简单。
在终端中使用 ls -l `xcrun -show-sdk-path` 将显示您选择了哪个 SDK。
参见 https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution。
使用 gcc 10.2。
https://developer.apple.com/documentation/accelerate.
据报道，对于某些非 Apple 工具链，CPPFLAGS 需要包含 -D__ACCELERATE__：对于来自 LLVM 的 clang 则不需要。
例如，https://en.wikipedia.org/wiki/Grand_Central_Dispatch 。
可以通过 Unix TeX Live 安装脚本获得一个基本等效的 TeX 安装。
例如，通过 tlmgr install helvetic inconsolata texinfo 。
添加检查 CRAN 所需的所有软件包，这将增加到大约 600MB。
只需从 R 的安装程序中选择该组件即可：在“安装类型”屏幕中选择“自定义”，然后仅选择“Tcl/Tk 8.6.11”组件。
使用 --enable-aqua 配置 Tk。
在不太可能的情况下，如果报告的版本没有以 1.8.0、11 或更高版本开头，则需要更新您的 Java。
在撰写本文时，对于 ‘arm64’ 来说，还没有。