"Fossies" - the Fresh Open Source Software Archive

Member "otp_src_23.1/HOWTO/INSTALL.md" (22 Sep 2020, 33912 Bytes) of package /linux/misc/otp_src_23.1.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

Building and Installing Erlang/OTP


This document describes how to build and install Erlang/OTP-%OTP-REL%. Erlang/OTP should be possible to build from source on any Unix/Linux system, including OS X. You are advised to read the whole document before attempting to build and install Erlang/OTP.

The source code can be downloaded from the official site of Erlang/OTP or GitHub. * http://www.erlang.org * https://github.com/erlang/otp

Required Utilities

These are the tools you need in order to unpack and build Erlang/OTP.



Building in Git

Building on OS X


Optional Utilities

Some applications are automatically skipped if the dependencies aren’t met. Here is a list of utilities needed for those applications. You will also find the utilities needed for building the documentation.


Building Documentation

How to Build and Install Erlang/OTP

The following instructions are for building the released source tar ball.

The variable $ERL_TOP will be mentioned a lot of times. It refers to the top directory in the source tree. More information about $ERL_TOP can be found in the make and $ERL_TOP section below. If you are building in git you probably want to take a look at the Building in Git section below before proceeding.


Start by unpacking the Erlang/OTP distribution file with your GNU compatible TAR program.

$ tar -zxf otp_src_%OTP-VSN%.tar.gz    # Assuming bash/sh

Now change directory into the base directory and set the $ERL_TOP variable.

$ cd otp_src_%OTP-VSN%
$ export ERL_TOP=`pwd`    # Assuming bash/sh


Run the following commands to configure the build:

$ ./configure [ options ]

NOTE: If you are building Erlang/OTP from git you will need to run ./otp_build autoconf to generate the configure scripts.

By default, Erlang/OTP release will be installed in /usr/local/{bin,lib/erlang}. If you for instance don’t have the permission to install in the standard location, you can install Erlang/OTP somewhere else. For example, to install in /opt/erlang/%OTP-VSN%/{bin,lib/erlang}, use the --prefix=/opt/erlang/%OTP-VSN% option.

On some platforms Perl may behave strangely if certain locales are set. If you get errors when building, try setting the LANG variable:

$ export LANG=C   # Assuming bash/sh


Build the Erlang/OTP release.

$ make


Before installation you should test whether your build is working properly by running our smoke test. The smoke test is a subset of the complete Erlang/OTP test suites. First you will need to build and release the test suites.

$ make release_tests

This creates an additional folder in $ERL_TOP/release called tests. Now, it’s time to start the smoke test.

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

To verify that everything is ok you should open $ERL_TOP/release/tests/test_server/index.html in your web browser and make sure that there are zero failed test cases.

NOTE: On builds without crypto, ssl and ssh there is a failed test case for undefined functions. Verify that the failed test case log only shows calls to skipped applications.


You are now ready to install the Erlang/OTP release! The following command will install the release on your system.

$ make install


You should now have a working release of Erlang/OTP! Jump to System Principles for instructions on running Erlang/OTP.

How to Build the Documentation

Make sure you’re in the top directory in the source tree.

$ cd $ERL_TOP

If you have just built Erlang/OTP in the current source tree, you have already ran configure and do not need to do this again; otherwise, run configure.

$ ./configure [Configure Args]

When building the documentation you need a full Erlang/OTP-%OTP-VSN% system in the $PATH.

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

For the FOP print formatter, two steps must be taken:

Build the documentation.

$ make docs

It is possible to limit which types of documentation is build by passing the DOC_TARGETS environment variable to make docs. The currently available types are: html, pdf, man and chunks. Example:

$ make docs DOC_TARGETS=chunks

Build Issues

We have sometimes experienced problems with Oracle’s java running out of memory when running fop. Increasing the amount of memory available as follows has in our case solved the problem.

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

More information can be found at * http://xmlgraphics.apache.org/fop/0.95/running.html#memory.

How to Install the Documentation

The documentation can be installed either using the install-docs target, or using the release_docs target.

It is possible to limit which types of documentation is released using the same DOC_TARGETS environment variable as when building documentation.

Accessing the Documentation

After installation you can access the documentation by

How to Install the Pre-formatted Documentation

Pre-formatted html documentation and man pages can be downloaded from * http://www.erlang.org/download.html.

Extract the html archive in the installation directory.

$ cd <ReleaseDir>
$ tar -zxf otp_html_%OTP-VSN%.tar.gz

For erl -man <page> to work the Unix manual pages have to be installed in the same way, i.e.

$ cd <ReleaseDir>
$ tar -zxf otp_man_%OTP-VSN%.tar.gz

Where <ReleaseDir> is

Advanced configuration and build of Erlang/OTP

If you want to tailor your Erlang/OTP build and installation, please read on for detailed information about the individual steps.

make and $ERL_TOP

All the makefiles in the entire directory tree use the environment variable ERL_TOP to find the absolute path of the installation. The configure script will figure this out and set it in the top level Makefile (which, when building, it will pass on). However, when developing it is sometimes convenient to be able to run make in a subdirectory. To do this you must set the ERL_TOP variable before you run make.

For example, assume your GNU make program is called make and you want to rebuild the application STDLIB, then you could do:

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

where <Dir> would be what you find ERL_TOP is set to in the top level Makefile.

otp_build vs configure/make

Building Erlang/OTP can be done either by using the $ERL_TOP/otp_build script, or by invoking $ERL_TOP/configure and make directly. Building using otp_build is easier since it involves fewer steps, but the otp_build build procedure is not as flexible as the configure/make build procedure. The binary releases for Windows that we deliver are built using otp_build.


The configure script is created by the GNU autoconf utility, which checks for system specific features and then creates a number of makefiles.

The configure script allows you to customize a number of parameters; type ./configure --help or ./configure --help=recursive for details. ./configure --help=recursive will give help for all configure scripts in all applications.

One of the things you can specify is where Erlang/OTP should be installed. By default Erlang/OTP will be installed in /usr/local/{bin,lib/erlang}. To keep the same structure but install in a different place, <Dir> say, use the --prefix argument like this: ./configure --prefix=<Dir>.

Some of the available configure options are:

If you or your system has special requirements please read the Makefile for additional configuration information.

Atomic Memory Operations and the VM

The VM with SMP support makes quite a heavy use of atomic memory operations. An implementation providing native atomic memory operations is therefore very important when building Erlang/OTP. By default the VM will refuse to build if native atomic memory operations are not available.

Erlang/OTP itself provides implementations of native atomic memory operations that can be used when compiling with a gcc compatible compiler for 32/64-bit x86, 32/64-bit SPARC V9, 32-bit PowerPC, or 32-bit Tile. When compiling with a gcc compatible compiler for other architectures, the VM may be able to make use of native atomic operations using the __atomic_* builtins (may be available when using a gcc of at least version 4.7) and/or using the __sync_* builtins (may be available when using a gcc of at least version 4.1). If only the gcc’s __sync_* builtins are available, the performance will suffer. Such a configuration should only be used as a last resort. When compiling on Windows using a MicroSoft Visual C++ compiler native atomic memory operations are provided by Windows APIs.

Native atomic implementation in the order preferred: 1. The implementation provided by Erlang/OTP. 2. The API provided by Windows. 3. The implementation based on the gcc __atomic_* builtins. 4. If none of the above are available for your architecture/compiler, you are recommended to build and install libatomic_ops before building Erlang/OTP. The libatomic_ops library provides native atomic memory operations for a variety of architectures and compilers. When building Erlang/OTP you need to inform the build system of where the libatomic_ops library is installed using the --with-libatomic_ops=PATH configure switch. 5. As a last resort, the implementation solely based on the gcc __sync_* builtins. This will however cause lots of expensive and unnecessary memory barrier instructions to be issued. That is, performance will suffer. The configure script will warn at the end of its execution if it cannot find any other alternative than this.


Building Erlang/OTP on a relatively fast computer takes approximately 5 minutes. To speed it up, you can utilize parallel make with the -j<num_jobs> option.

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

If you’ve upgraded the source with a patch you may need to clean up from previous builds before the new build. Make sure to read the Pre-built Source Release section below before doing a make clean.

Within Git

When building in a Git working directory you also have to have a GNU autoconf of at least version 2.59 on your system, because you need to generate the configure scripts before you can start building.

The configure scripts are generated by invoking ./otp_build autoconf in the $ERL_TOP directory. The configure scripts also have to be regenerated when a configure.in or aclocal.m4 file has been modified. Note that when checking out a branch a configure.in or aclocal.m4 file may change content, and you may therefore have to regenerate the configure scripts when checking out a branch. Regenerated configure scripts imply that you have to run configure and build again.

NOTE: Running ./otp_build autoconf is not needed when building an unmodified version of the released source.

Other useful information can be found at our GitHub wiki: * http://wiki.github.com/erlang/otp

OS X (Darwin)

Make sure that the command hostname returns a valid fully qualified host name (this is configured in /etc/hostconfig). Otherwise you might experience problems when running distributed systems.

If you develop linked-in drivers (shared library) you need to link using gcc and the flags -bundle -flat_namespace -undefined suppress. You also include -fno-common in CFLAGS when compiling. Use .so as the library suffix.

If you have Xcode 4.3, or later, you will also need to download “Command Line Tools” via the Downloads preference pane in Xcode.

Building with wxErlang

If you want to build the wx application, you will need to get wxWidgets-3.0 (wxWidgets-3.0.3.tar.bz2 from https://github.com/wxWidgets/wxWidgets/releases/download/v3.0.3/wxWidgets-3.0.3.tar.bz2) or get it from github with bug fixes:

$ git clone --branch WX_3_0_BRANCH git@github.com:wxWidgets/wxWidgets.git

The wxWidgets-3.1 version should also work if 2.8 compatibility is enabled, add --enable-compat28 to configure commands below.

Configure and build wxWidgets (shared library on linux):

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

Configure and build wxWidgets (static library on linux):

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

Configure and build wxWidgets (on Mavericks - 10.9):

$ ./configure --with-cocoa --prefix=/usr/local
or without support for old versions and with static libs
$ ./configure --with-cocoa --prefix=/usr/local --with-macosx-version-min=10.9 --disable-shared
$ make
$ sudo make install
$ export PATH=/usr/local/bin:$PATH

Check that you got the correct wx-config

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

Build Erlang/OTP

$ export PATH=/usr/local/bin:$PATH
$ cd $ERL_TOP
$ ./configure
$ make
$ sudo make install

Pre-built Source Release

The source release is delivered with a lot of platform independent build results already pre-built. If you want to remove these pre-built files, invoke ./otp_build remove_prebuilt_files from the $ERL_TOP directory. After you have done this, you can build exactly the same way as before, but the build process will take a much longer time.

WARNING: Doing make clean in an arbitrary directory of the source tree, may remove files needed for bootstrapping the build.

Doing ./otp_build save_bootstrap from the $ERL_TOP directory before doing make clean will ensure that it will be possible to build after doing make clean. ./otp_build save_bootstrap will be invoked automatically when make is invoked from $ERL_TOP with either the clean target, or the default target. It is also automatically invoked if ./otp_build remove_prebuilt_files is invoked.

If you need to verify the bootstrap beam files match the provided source files, use ./otp_build update_primary to create a new commit that contains differences, if any exist.

How to Build a Debug Enabled Erlang RunTime System

After completing all the normal building steps described above a debug enabled runtime system can be built. To do this you have to change directory to $ERL_TOP/erts/emulator and execute:

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

This will produce a beam.smp.debug executable. The file are installed along side with the normal (opt) version beam.smp.

To start the debug enabled runtime system execute:

$ $ERL_TOP/bin/cerl -debug

The debug enabled runtime system features lock violation checking, assert checking and various sanity checks to help a developer ensure correctness. Some of these features can be enabled on a normal beam using appropriate configure options.

There are other types of runtime systems that can be built as well using the similar steps just described.

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

where $TYPE is opt, gcov, gprof, debug, valgrind, or lcnt. These different beam types are useful for debugging and profiling purposes.


When doing make install and the default installation prefix is used, relative symbolic links will be created from /usr/local/bin to all public Erlang/OTP executables in /usr/local/lib/erlang/bin. The installation phase will try to create relative symbolic links as long as --bindir and the Erlang bin directory, located under --libdir, both have --exec-prefix as prefix. Where --exec-prefix defaults to --prefix. --prefix, --exec-prefix, --bindir, and --libdir are all arguments that can be passed to configure. One can force relative, or absolute links by passing BINDIR_SYMLINKS=relative|absolute as arguments to make during the install phase. Note that such a request might cause a failure if the request cannot be satisfied.


Using HiPE

HiPE supports the following system configurations:

HiPE is automatically enabled on the following systems:

On other supported systems, see Advanced Configure on how to enable HiPE.

If you are running on a platform supporting HiPE and if you have not disabled HiPE, you can compile a module into native code like this from the Erlang shell:

1> c(Module, native).


1> c(Module, [native|OtherOptions]).

Using the erlc program, write like this

$ erlc +native Module.erl

The native code will be placed into the beam file and automatically loaded when the beam file is loaded.

To add hipe options, write like this from the Erlang shell:

1> c(Module, [native,{hipe,HipeOptions}|MoreOptions]).

Use hipe:help_options/0 to print out the available options.

1> hipe:help_options().