2  构建和安装 Erlang/OTP

2  构建和安装 Erlang/OTP

本文档介绍了如何构建和安装 Erlang/OTP-26。Erlang/OTP 应该可以在任何 Unix/Linux 系统(包括 macOS)上从源代码构建。建议您在尝试构建和安装 Erlang/OTP 之前阅读整篇文档。

源代码可以从 Erlang/OTP 的官方网站或 GitHub 下载。

以下是在解包和构建 Erlang/OTP 时所需的工具。

  • GNU unzip 或现代解压缩工具。
  • 支持 GNU TAR 格式以处理长文件名的 TAR 程序。
  • GNU make
  • 编译器 - GNU C 编译器,gcc 或 LLVM 的 C 编译器前端,clang
  • Perl 5
  • ncursestermcaptermlib - 需要开发头文件和库,通常称为 ncurses-devel。使用 --without-termcap 选项在不使用任何这些库的情况下进行构建。请注意,在这种情况下,只能使用旧的 shell(不带任何行编辑功能)。
  • sed - 用于基本文本转换的流编辑器。
在 Git 中构建

构建方式与构建解包的 tar 文件相同。

在 macOS 上构建
  • Xcode - 通过 Mac App Store 下载和安装。在继续之前,请阅读有关 在 Mac 上构建 的内容。
  • 一个可以接受多个文件名的 install 程序。

如果未满足依赖关系,某些应用程序将自动跳过。以下是这些应用程序所需的工具列表。您还可以找到构建文档所需的工具。

  • OpenSSL - 用于安全套接字层和传输层安全的开源工具包。构建 crypto 应用程序需要它。此外,sslssh 需要一个可工作的 crypto 应用程序,如果缺少 OpenSSL,它们也会被跳过。 public_key 应用程序可以在没有 crypto 的情况下使用,但功能将非常有限。

    OpenSSL 的开发包(包括头文件)以及二进制命令程序 openssl 是必需的。至少需要 OpenSSL 0.9.8 版本。请从 http://www.openssl.org 了解更多信息并下载。

  • Oracle Java SE JDK - Java 开发工具包(标准版)。构建 jinterface 应用程序需要它。至少需要 JDK 1.6.0 版本。

    http://www.oracle.com/technetwork/java/javase/downloads 下载。我们还测试了 IBM 的 JDK 1.6.0。

  • flex - 在 Unix/Linux 上构建 megaco 应用程序的 flex 扫描器需要头文件和库。

  • wxWidgets - 用于 GUI 应用程序的工具包。构建 wx 应用程序需要它。至少需要 wxWidgets 3.0 版本。

    http://sourceforge.net/projects/wxwindows/files/3.0.0/ 下载,或从 GitHub 获取:https://github.com/wxWidgets/wxWidgets

    有关 wxWidgets 的更多说明,请阅读 使用 wxErlang 构建

以下说明适用于构建 发布的源代码 tar 包

变量 $ERL_TOP 会被多次提到。它指的是源代码树中的顶层目录。有关 $ERL_TOP 的更多信息,请参见以下 make 和 $ERL_TOP 部分。

首先使用您兼容 GNU 的 TAR 程序解包 Erlang/OTP 分发文件。

$ tar -zxf otp_src_26.2.3.tar.gz    # Assuming bash/sh

现在更改到基本目录并设置 $ERL_TOP 变量。

$ cd otp_src_26.2.3
$ export ERL_TOP=`pwd`    # Assuming bash/sh

运行以下命令配置构建

$ ./configure [ options ]

默认情况下,Erlang/OTP 版本将安装在 /usr/local/{bin,lib/erlang} 中。例如,如果您没有权限安装到标准位置,则可以将 Erlang/OTP 安装到其他位置。例如,要安装到 /opt/erlang/26.2.3/{bin,lib/erlang},请使用 --prefix=/opt/erlang/26.2.3 选项。

在某些平台上,如果设置了某些区域设置,Perl 的行为可能很奇怪。如果在构建时遇到错误,请尝试设置 LANG 变量

$ export LANG=C   # Assuming bash/sh

构建 Erlang/OTP 版本。

$ make

在安装之前,您应该通过运行我们的冒烟测试来测试您的构建是否正常工作。冒烟测试是完整的 Erlang/OTP 测试套件的子集。首先,您需要构建和发布测试套件。

$ make release_tests

这将在 $ERL_TOP/release 中创建一个名为 tests 的附加文件夹。现在,该启动冒烟测试了。

$ cd release/tests/test_server
$ $ERL_TOP/bin/erl -s ts install -s ts smoke_test batch -s init stop

要验证一切正常,您应该在网络浏览器中打开 $ERL_TOP/release/tests/test_server/index.html,并确保没有失败的测试用例。

注意

在没有 cryptosslssh 的构建中,有一个未定义函数的失败测试用例。验证失败的测试用例日志仅显示对跳过应用程序的调用。

现在您已准备好安装 Erlang/OTP 版本!以下命令将把版本安装到您的系统上。

$ make install

现在您应该有一个可工作的 Erlang/OTP 版本!转到 系统原理,获取有关运行 Erlang/OTP 的说明。

确保您位于源代码树的顶层目录中。

$ cd $ERL_TOP

如果您刚刚在当前源代码树中构建了 Erlang/OTP,那么您已经运行了 configure,无需再次运行;否则,请运行 configure

$ ./configure [Configure Args]

构建文档时,您需要在 $PATH 中拥有完整的 Erlang/OTP-26.2.3 系统。

$ export PATH=$ERL_TOP/bin:$PATH     # Assuming bash/sh

对于 FOP 打印格式化程序,需要采取两个步骤

  • $FOP_HOME 中添加您安装的 fop 位置。

    $ export FOP_HOME=/path/to/fop/dir # Assuming bash/sh
  • fop 脚本(在 $FOP_HOME 中)添加到您的 $PATH 中,方法是将 $FOP_HOME 添加到 $PATH,或将 fop 脚本复制到您 $PATH 中已有的目录中。

构建文档。

$ make docs

可以通过将 DOC_TARGETS 环境变量传递给 make docs 来限制构建的文档类型。当前可用的类型包括:htmlpdfmanchunks。示例

$ make docs DOC_TARGETS=chunks
构建问题

我们有时会遇到 Oracle 的 java 在运行 fop 时内存不足的问题。在我们的案例中,增加可用内存量可以解决问题。

$ export FOP_OPTS="-Xmx<Installed amount of RAM in MB>m"

更多信息请参见

文档可以通过 install-docs 目标或 release_docs 目标进行安装。

  • 如果您使用 install 目标安装了 Erlang/OTP,请使用 install-docs 目标安装文档。将使用由 configure 确定的安装位置。 $DESTDIR 的使用方式与执行 make install 时相同。

    $ make install-docs
  • 如果您使用 release 目标安装了 Erlang/OTP,请使用 release_docs 目标安装文档。通常情况下,您希望使用与调用 make release 时相同的 RELEASE_ROOT

    $ make release_docs RELEASE_ROOT=<release dir>

可以使用与构建文档时相同的 DOC_TARGETS 环境变量来限制发布的文档类型。

安装后,您可以通过以下方式访问文档

  • 阅读手册页。确保 erl 引用的是安装的版本。例如 /usr/local/bin/erl。尝试查看 Mnesia 的手册页

    $ erl -man mnesia
  • 通过加载页面 /usr/local/lib/erlang/doc/erlang/index.html<BaseDir>/lib/erlang/doc/erlang/index.html(如果使用了 prefix 选项)来浏览 html 页面。

  • 使用内置的 shell 函数 h/1,2,3ht/1,2,3 阅读嵌入式文档。

预格式化的 html 文档手册页 可以从以下位置下载

将 html 存档解压缩到安装目录中。

$ cd <ReleaseDir>
$ tar -zxf otp_html_26.2.3.tar.gz

为了使 erl -man <page> 能够工作,Unix 手册页必须以相同的方式安装,即

$ cd <ReleaseDir>
$ tar -zxf otp_man_26.2.3.tar.gz

其中 <ReleaseDir>

  • <PrefixDir>/lib/erlang,如果您使用 make install 安装了 Erlang/OTP。
  • $DESTDIR<PrefixDir>/lib/erlang,如果您使用 make install DESTDIR=<TmpInstallDir> 安装了 Erlang/OTP。
  • RELEASE_ROOT,如果您使用 make release RELEASE_ROOT=<ReleaseDir> 安装。

如果您想定制 Erlang/OTP 的构建和安装,请继续阅读以获取有关各个步骤的详细信息。

整个目录树中的所有 Makefile 都使用环境变量 ERL_TOP 来查找安装的绝对路径。 configure 脚本会找出这个路径并在顶层 Makefile 中设置它(在构建时,它会传递下去)。但是,在开发时,有时需要能够在子目录中运行 make。为此,您必须在运行 make 之前设置 ERL_TOP 变量。

例如,假设您的 GNU make 程序名为 make,并且您想重新构建应用程序 STDLIB,那么您可以执行以下操作:

$ cd lib/stdlib; env ERL_TOP=<Dir> make

其中 <Dir> 将是您在顶层 Makefile 中设置的 ERL_TOP 的值。

构建 Erlang/OTP 可以通过使用 $ERL_TOP/otp_build 脚本完成,也可以通过直接调用 $ERL_TOP/configuremake 完成。使用 otp_build 构建更简单,因为它涉及的步骤更少,但 otp_build 构建过程不如 configure/make 构建过程灵活。我们交付的 Windows 二进制版本使用 otp_build 构建。

configure 脚本由 GNU autoconf 实用程序创建,该实用程序检查系统特定功能,然后创建多个 makefile。

configure 脚本允许您自定义许多参数;键入 ./configure --help./configure --help=recursive 获取详细信息。 ./configure --help=recursive 将提供所有应用程序中所有 configure 脚本的帮助信息。

您可以指定的一个参数是 Erlang/OTP 的安装位置。默认情况下,Erlang/OTP 将安装在 /usr/local/{bin,lib/erlang} 中。要保持相同的结构,但安装在不同的位置,例如 <Dir>,请使用 --prefix 参数,如下所示:./configure --prefix=<Dir>

一些可用的 configure 选项是

  • --prefix=PATH - 指定安装前缀。
  • --disable-parallel-configure - 禁用 configure 脚本的并行执行(默认情况下启用并行执行)。
  • --{enable,disable}-jit - 强制启用或禁用 JIT。
  • --{enable,disable}-kernel-poll - 内核轮询支持(如果可能,默认情况下启用)。
  • --enable-m64-build - 使用 -m64 标志构建 64 位二进制文件,以传递给 (g)cc
  • --enable-m32-build - 使用 -m32 标志构建 32 位二进制文件,以传递给 (g)cc
  • --{enable,disable}-pie - 构建位置无关可执行二进制文件。
  • --with-assumed-cache-line-size=SIZE - 设置假设的缓存行大小(以字节为单位)。默认值为 64。有效值为 16 到 8192(包括)之间的 2 的幂。运行时系统使用此值来尝试避免错误共享。值过大将浪费内存。值过小将增加错误共享的数量。
  • --{with,without}-termcap - termcap(without 表示只能使用旧的 Erlang shell)。
  • --with-javac=JAVAC - 指定要使用的 Java 编译器。
  • --{with,without}-javac - Java 编译器(without 表示不会构建 jinterface 应用程序)。
  • --{enable,disable}-builtin-zlib - 使用内置的 zlib 源代码。
  • --{enable,disable}-dynamic-ssl-lib - 在链接 crypto NIF 时启用或禁用动态 OpenSSL 库。默认情况下,将进行动态链接,除非它不起作用,或者它是一个 Windows 系统。
  • --{with,without}-ssl - OpenSSL(without 表示不会构建 cryptosshssl)。
  • --with-ssl=PATH - 指定 OpenSSL include 和 lib 目录的基准位置。
  • --with-ssl-incl=PATH - 指定 OpenSSL include 目录的基准位置(如果与 --with-ssl=PATH 指定的基准位置不同)。
  • --with-ssl-zlib=PATH - 用于链接 crypto NIF 的静态 zlib 库的路径。此 zlib 库通常不需要,但在某些情况下可能需要链接 NIF。
  • --with-ssl-lib-subdir=RELATIVE_PATH - 指定要搜索的额外 OpenSSL lib 子目录(相对于基准目录)。
  • --with-ssl-rpath=yes|no|PATHS - OpenSSL 的运行时库路径。默认值为 yes,相当于多个标准位置。如果为 no,则不会使用任何运行时库路径。任何其他值都应该是用逗号或冒号分隔的路径列表。
  • --with-libatomic_ops=PATH - 使用 libatomic_ops 库进行原子内存访问。如果 configure 通知您没有可用的本地原子实现,您通常想要尝试使用 libatomic_ops 库。它可以从 https://github.com/ivmai/libatomic_ops/ 下载。
  • --disable-smp-require-native-atomics - 默认情况下,如果要构建 SMP 运行时系统,并且没有找到本地原子内存访问的实现,configure 将失败。如果发生这种情况,建议您找到一个可用的本地原子实现,例如使用 libatomic_ops,但通过传递 --disable-smp-require-native-atomics,您可以使用基于互斥锁或自旋锁的回退实现进行构建。但是,如果没有本地原子内存访问的实现,SMP 运行时系统的性能将受到极大影响。
  • --enable-static-{nifs,drivers} - 为了允许在不支持库动态链接的操作系统上使用 nif 和驱动程序,可以将 nif 和驱动程序与主 Erlang VM 二进制文件静态链接。这可以通过将逗号分隔的列表传递给要静态链接的存档来完成。例如,--enable-static-nifs=/home/$USER/my_nif.a。路径必须是绝对路径。对于驱动程序,驱动程序名称必须与文件名相同。在编译 nif/驱动程序的 .o 文件时,您还必须定义 STATIC_ERLANG_NIF_LIBNAME(请参阅 erl_nif 文档)或 STATIC_ERLANG_DRIVER。如果您的 nif/驱动程序依赖于其他动态库,那么您现在必须将该库链接到 Erlang VM 二进制文件。这可以通过将 LIBS=-llibname 传递给 configure 来轻松实现。
  • --without-$app - 默认情况下,Erlang/OTP 中的所有应用程序都将包含在发行版中。如果不需要,可以指定 Erlang/OTP 应该在没有一个或多个应用程序的情况下编译,例如 --without-wx。应用程序之间没有自动依赖关系处理。如果您禁用了另一个应用程序所依赖的应用程序,那么您也必须禁用依赖应用程序。
  • --enable-gettimeofday-as-os-system-time - 强制使用 gettimeofday() 获取操作系统系统时间。
  • --enable-prefer-elapsed-monotonic-time-during-suspend - 在挂起期间优先使用具有经过时间的操作系统单调时间源。
  • --disable-prefer-elapsed-monotonic-time-during-suspend - 在挂起期间不要优先使用具有经过时间的操作系统单调时间源。
  • --with-clock-resolution=high|low - 尝试为操作系统系统时间和操作系统单调时间找到比默认选择更高的或更低的分辨率的时钟源。请注意,与默认选择的时钟源相比,这两种替代方法都可能对性能和可扩展性产生负面影响。
  • --disable-saved-compile-time - 禁用在模拟器二进制文件中保存编译日期和时间。
  • --enable-ei-dynamic-lib - 使 erl_interface 除了通常构建的存档外,还构建共享库。

如果您或您的系统有特殊需求,请阅读 Makefile 以获取更多配置信息。

configure 检查的重要变量
编译器和链接器
  • CC - C 编译器。
  • CFLAGS - C 编译器标志。默认值为 "-g -O2"。如果设置了它,这些标志将被删除。
  • STATIC_CFLAGS - 静态 C 编译器标志。
  • CFLAG_RUNTIME_LIBRARY_PATH - 此标志应设置共享库的运行时库搜索路径。请注意,这实际上是一个链接器标志,但它需要通过编译器传递。
  • CPP - C 预处理器。
  • CPPFLAGS - C 预处理器标志。
  • CXX - C++ 编译器。
  • CXXFLAGS - C++ 编译器标志。
  • LD - 链接器。
  • LDFLAGS - 链接器标志。
  • LIBS - 库。
动态 Erlang 驱动程序链接
注意

要么设置所有 DED_LD* 变量(除 DED_LDFLAGS_CONFTEST 外),要么都不设置。

  • DED_LD - 动态加载的 Erlang 驱动程序的链接器。
  • DED_LDFLAGS - 与 DED_LD 一起使用的链接器标志。
  • DED_LDFLAGS_CONFTEST - 如果无法在 configure 链接测试中使用 DED_LDFLAGS,则与 DED_LD 一起使用的链接器标志。如果没有设置,则将在 configure 测试中使用 DED_LDFLAGS
  • DED_LD_FLAG_RUNTIME_LIBRARY_PATH - 此标志应设置在使用 DED_LD 链接时,共享库的运行时库搜索路径。
大文件支持
注意

要么设置所有 LFS_* 变量,要么都不设置。

  • LFS_CFLAGS - 大文件支持 C 编译器标志。
  • LFS_LDFLAGS - 大文件支持链接器标志。
  • LFS_LIBS - 大文件支持库。
其他工具
  • RANLIB - ranlib 存档索引工具。
  • AR - ar 存档工具。
  • GETCONF - getconf 系统配置检查工具。 getconf 当前用于找出要使用的大文件支持标志,以及在 Linux 系统上找出我们是否有 NPTL 线程库。
更新 configure 脚本

生成的 configure 脚本现在已包含在 git 存储库中。

如果您修改了任何 configure.in 文件或 erts/aclocal.m4 文件,则需要在更改生效之前重新生成 configure 脚本。首先,确保您的路径中包含版本 2.69 的 GNU autoconf。然后在 $ERL_TOP 目录中执行 ./otp_build update_configure [--no-commit]otp_build 脚本将验证 autoconf 是否为正确版本,如果它为任何其他版本,则将拒绝更新 configure 脚本。

原子内存操作和虚拟机

支持 SMP 的虚拟机大量使用原子内存操作。因此,在构建 Erlang/OTP 时,提供原生原子内存操作的实现非常重要。默认情况下,如果无法使用原生原子内存操作,虚拟机将拒绝构建。

Erlang/OTP 本身提供了原生原子内存操作的实现,可以在使用与 gcc 兼容的编译器编译 32/64 位 x86、32/64 位 SPARC V9、32 位 PowerPC 或 32 位 Tile 时使用。当使用与 gcc 兼容的编译器编译其他架构时,虚拟机可能能够使用原生原子操作,使用 __atomic_* 内置函数(可能在使用至少 4.7 版本的 gcc 时可用)和/或使用 __sync_* 内置函数(可能在使用至少 4.1 版本的 gcc 时可用)。如果仅提供 gcc__sync_* 内置函数,性能会下降。这种配置应该只作为最后的手段使用。在 Windows 上使用 MicroSoft Visual C++ 编译器编译时,原生原子内存操作由 Windows API 提供。

原生原子实现,按优先顺序排列

  1. Erlang/OTP 提供的实现。
  2. Windows 提供的 API。
  3. 基于 gcc __atomic_* 内置函数的实现。
  4. 如果您的架构/编译器不提供上述任何一种,建议您在构建 Erlang/OTP 之前构建并安装 libatomic_opslibatomic_ops 库为各种架构和编译器提供了原生原子内存操作。在构建 Erlang/OTP 时,您需要使用 --with-libatomic_ops=PATH configure 开关通知构建系统 libatomic_ops 库的安装位置。
  5. 作为最后的手段,仅基于 gcc __sync_* 内置函数的实现。但这会导致发出大量昂贵且不必要的内存屏障指令。也就是说,性能会下降。如果 configure 脚本无法找到除此之外的其他替代方案,它将在执行结束时发出警告。

在速度相对较快的计算机上构建 Erlang/OTP 大概需要 5 分钟。为了加快速度,您可以使用带有 -j<num_jobs> 选项的并行 make。

$ export MAKEFLAGS=-j8    # Assuming bash/sh
$ make

如果您使用补丁升级了源代码,可能需要在新的构建之前清理之前的构建。在执行 make clean 之前,请务必阅读以下的 预构建源代码发行版 部分。

其他有用的信息可以在我们的 GitHub wiki 中找到

在 Git 中

构建方式与构建解包的 tar 文件相同。

macOS (Darwin)

确保命令 hostname 返回一个有效的完全限定主机名(这在 /etc/hostconfig 中配置)。否则,您可能会在运行分布式系统时遇到问题。

如果您开发链接的驱动程序(共享库),则需要使用 gcc 和标志 -bundle -flat_namespace -undefined suppress 进行链接。您还需要在编译时在 CFLAGS 中包含 -fno-common。使用 .so 作为库后缀。

如果您有 Xcode 4.3 或更高版本,您还需要通过 Xcode 中的“下载”首选项窗格下载“命令行工具”。

使用 wxErlang 构建

建议使用 wxWidgets-3.2.x 构建 wx 应用程序(wxWidgets-3.0.x 也能正常工作)。从 https://www.wxwidgets.org/downloadshttps://github.com/wxWidgets/wxWidgets 下载。建议使用 3.2 系列中的最新版本,在撰写本文时为 3.2.2.1。

请注意,wxWidgets-3.3 版本是实验性的,但如果通过在下面的 configure 命令中添加 --enable-compat30 来启用 3.0 兼容性,它们也应该能正常工作。

在所有其他平台上,共享库的构建方式如下

$ ./configure --prefix=/usr/local
$ make && sudo make install
$ export PATH=/usr/local/bin:$PATH

在 Linux 上,静态库的构建方式如下

$ export CFLAGS=-fPIC
$ export CXXFLAGS=-fPIC
$ ./configure --prefix=/usr/local --disable-shared
$ make && sudo make install
$ export PATH=/usr/local/bin:$PATH

在 macOs 上,与 macOS 13(Ventura)及更高版本兼容的静态库的构建方式如下

$ ./configure --prefix=/usr/local --with-macosx-version-min=13.0 --disable-shared
$ make
$ sudo make install
$ export PATH=/usr/local/bin:$PATH

验证构建和安装是否成功

$ which wx-config && wx-config --version-full

预期输出为一行上的 /usr/local/bin/wx-config,后跟完整版本号。例如,如果您构建了 3.2.2.1 版本,则预期输出为

/usr/local/bin/wx-config
3.2.2.1

以通常的方式构建 Erlang/OTP。要验证 wx 应用程序是否正常运行,请运行以下命令

$ erl -run wx demo
预构建源代码发行版

源代码发行版附带了许多平台无关的构建结果,这些结果已经预先构建。如果您想删除这些预构建文件,请从 $ERL_TOP 目录调用 ./otp_build remove_prebuilt_files。完成此操作后,您可以像以前一样构建,但构建过程将花费更长的时间。

警告

在源代码树的任意目录中执行 make clean,可能会删除引导构建所需的必要文件。

在执行 make clean 之前,从 $ERL_TOP 目录执行 ./otp_build save_bootstrap 将确保能够在执行 make clean 之后进行构建。当从 $ERL_TOP 使用 clean 目标或默认目标调用 make 时,会自动调用 ./otp_build save_bootstrap。如果调用 ./otp_build remove_prebuilt_files,也会自动调用它。

如果您需要验证引导 beam 文件是否与提供的源文件匹配,请使用 ./otp_build update_primary 创建一个包含差异的新提交(如果有)。

如何构建启用调试的 Erlang 运行时系统

完成上述所有正常的构建步骤后,可以构建启用调试的运行时系统。要执行此操作,您必须将目录更改为 $ERL_TOP/erts/emulator 并执行

$ (cd $ERL_TOP/erts/emulator && make debug)

这将生成一个 beam.smp.debug 可执行文件。该文件与正常(opt)版本 beam.smp 一起安装。

要启动启用调试的运行时系统,请执行

$ $ERL_TOP/bin/cerl -debug

启用调试的运行时系统具有锁违规检查、断言检查和各种健全性检查,以帮助开发人员确保正确性。可以使用适当的配置选项在正常的 beam 上启用其中一些功能。

还可以使用类似的步骤构建其他类型的运行时系统。

$ (cd $ERL_TOP/erts/emulator && make $TYPE)

其中 $TYPEoptgcovgprofdebugvalgrindasanlcnt。这些不同的 beam 类型可用于调试和分析目的。

  • 使用 DESTDIR 进行分阶段安装。您可以在临时目录中执行安装阶段,然后使用 DESTDIR 变量将安装移动到正确的位置

    $ make DESTDIR=<tmp install dir> install

    安装将创建在以 $DESTDIR 为前缀的位置。但是,它不能从那里运行。它需要移动到正确的位置才能运行。如果未设置 DESTDIR 但设置了 INSTALL_PREFIX,则 DESTDIR 将设置为 INSTALL_PREFIX。请注意,在 R13B04 之前的版本中,INSTALL_PREFIX 有错误,其行为与 EXTRA_PREFIX 相似(见下文)。使用 DESTDIR 进行安装过程有很多应用场景,例如在创建软件包、交叉编译等时。以下是一个示例,其中安装应位于 /opt/local

    $ ./configure --prefix=/opt/local
    $ make
    $ make DESTDIR=/tmp/erlang-build install
    $ cd /tmp/erlang-build/opt/local
    $     # gnu-tar is used in this example
    $ tar -zcf /home/me/my-erlang-build.tgz *
    $ su -
    Password: *****
    $ cd /opt/local
    $ tar -zxf /home/me/my-erlang-build.tgz
  • 使用 release 目标进行安装。您可以使用 release 目标在您喜欢的任何目录中创建安装,而不是执行 make install,并自行运行 Install 脚本。 RELEASE_ROOT 用于指定应创建安装的目录。如果您使用 make install 进行安装,默认情况下,此目录最终将位于 /usr/local/lib/erlang 下。在配置阶段提供的以及 DESTDIRINSTALL_PREFIX 中提供的所有安装路径都将被忽略。如果您希望从特定的 bin 目录链接到安装,则必须自行设置这些链接。以下是一个示例,其中 Erlang/OTP 应位于 /home/me/OTP

    $ ./configure
    $ make
    $ make RELEASE_ROOT=/home/me/OTP release
    $ cd /home/me/OTP
    $ ./Install -minimal /home/me/OTP
    $ mkdir -p /home/me/bin
    $ cd /home/me/bin
    $ ln -s /home/me/OTP/bin/erl erl
    $ ln -s /home/me/OTP/bin/erlc erlc
    $ ln -s /home/me/OTP/bin/escript escript
    ...

    目前,Install 脚本应在它所在的目录(顶层目录)中按如下方式调用

    $ ./Install [-cross] [-minimal|-sasl] <ERL_ROOT>

    其中

    • -minimal 创建一个启动最少应用程序的安装,即仅启动 kernelstdlib。最小系统通常就足够了,也是 make install 使用的系统。
    • -sasl 创建一个也启动 sasl 应用程序的安装。
    • -cross 用于交叉编译。通知安装脚本它是在构建机器上运行的。
    • <ERL_ROOT> - 运行时使用的 Erlang 安装的绝对路径。这通常与当前工作目录相同,但不必相同。它可以遵循任何其他路径通过文件系统到达同一个目录。

    如果既没有传递 -minimal,也没有传递 -sasl 作为参数,您将被提示。

  • 使用 EXTRA_PREFIX 测试安装。在执行 make install 时,EXTRA_PREFIX 变量的内容将作为所有安装路径的前缀。请注意,EXTRA_PREFIXDESTDIR 类似,但它**不**具有与 DESTDIR 相同的效果。安装可以并且必须从 EXTRA_PREFIX 指定的位置运行。也就是说,如果您想在执行没有 EXTRA_PREFIX 的真实安装之前,试用系统、运行测试套件等,它可能会很有用。

--bindir 中的符号链接

在执行 make install 并使用默认安装前缀时,将从 /usr/local/bin/usr/local/lib/erlang/bin 中的所有公共 Erlang/OTP 可执行文件创建相对符号链接。安装阶段将尝试创建相对符号链接,只要 --bindir 和位于 --libdir 下的 Erlang bin 目录都以 --exec-prefix 为前缀即可。其中 --exec-prefix 默认设置为 --prefix--prefix--exec-prefix--bindir--libdir 都是可以传递给 configure 的参数。可以通过在安装阶段将 BINDIR_SYMLINKS=relative|absolute 作为参数传递给 make 来强制创建相对链接或绝对链接。请注意,如果无法满足请求,则此类请求可能会导致失败。

Erlang/OTP 目前在以下硬件和操作系统上进行测试。这不是一个详尽的列表,但我们努力使其尽可能地保持最新。

架构

  • x86、x86-64
  • Aarch32、Aarch64
  • powerpc、powerpc64le

操作系统

  • Fedora 31
  • FreeBSD
  • macOS 10.4 - 11.2
  • MontaVista 4
  • NetBSD
  • OpenBSD
  • SLES 10、11、12
  • SunOS 5.11
  • Ubuntu 10.04 - 20.04
  • Windows 10、Windows Server 2019