aboutsummaryrefslogtreecommitdiffstats
path: root/xcomp/README
diff options
context:
space:
mode:
Diffstat (limited to 'xcomp/README')
-rw-r--r--xcomp/README539
1 files changed, 376 insertions, 163 deletions
diff --git a/xcomp/README b/xcomp/README
index dfda81fc8e..4cb577471a 100644
--- a/xcomp/README
+++ b/xcomp/README
@@ -1,10 +1,10 @@
-================================================================================
- Cross compiling Erlang/OTP
-================================================================================
+===============================================================================
+ Cross compiling Erlang/OTP
+===============================================================================
%CopyrightBegin%
-Copyright Ericsson AB 2009. All Rights Reserved.
+Copyright Ericsson AB 2009-2010. All Rights Reserved.
The contents of this file are subject to the Erlang Public License,
Version 1.1, (the "License"); you may not use this file except in
@@ -19,200 +19,413 @@ under the License.
%CopyrightEnd%
-================================================================================
+===============================================================================
+
+This document describes how to cross compile Erlang/OTP. Note that the support
+for cross compiling Erlang/OTP is in its early stage of development, and
+should be considered as experimental. You are encouraged to read the whole
+document before attempting to cross compile Erlang/OTP.
+
+Building Erlang/OTP can be done either by using the `$ERL_TOP/otp_build'
+script, or by invoking `configure' and `make' directly. The
+`erl-xcomp.conf.template' file contains all available configuration variables
+and can be used as a template when creating a configuration. See
+`erl-xcomp-TileraMDE2.0-tilepro.conf` and `erl-xcomp-x86_64-saf-linux-gnu.conf'
+for examples of working configurations.
+
+The configuration files can be passed to `$ERL_TOP/otp_build configure' using
+the `--xcomp-conf' command line argument. Note that `configure' doesn't accept
+this command line argument. When using the `configure' script directly, pass
+the configuration variables as arguments to `configure' (or exported in the
+environment). If the default behavior of a variable is satisfactory, the
+variable doesn't need to be set. However, the `configure' script will issue a
+warning when a default value is used. When a variable has been set, no warning
+will be issued.
+
+All Erlang/OTP applications except the `wx' application can be cross compiled.
+The build of the `wx' driver will currently be automatically disabled when
+cross compiling.
+
+Note, that `$ERL_TOP/otp_build configure' will produce a default configuration
+that differs from what `$ERL_TOP/configure' will produce by default. For
+example, currently `--disable-dynamic-ssl-lib' is added to the
+`$ERL_TOP/configure' command line arguments unless `--enable-dynamic-ssl-lib'
+has been explicitly passed. The defaults used by `$ERL_TOP/otp_build configure'
+may change at any time without prior notice.
+
+The build system, including cross compilation configuration variables used,
+may be subject to non backward compatible changes without prior notice.
+Current cross build system has been tested when cross compiling some Linux/GNU
+systems, but has only been partly tested for more esoteric platforms. The
+VxWorks example file is highly dependent on our environment and is here more
+or less only for internal use.
-This directory contains a configuration file template and configuration examples
-for cross compiling Erlang/OTP. The configuration files contain configuration
-variables and should be supplied to the $ERL_TOP/otp_build when setting up an
-appropriate environment for cross compiling. The currently used configuration
-variables are described later in this document.
+Please submit any patches for cross compiling in a way consistent with this
+system. All input is welcome as we have a very limited set of cross compiling
+environments to test with. If a new configuration variable is needed, add it
+to `$ERL_TOP/xcomp/erl-xcomp.conf.template', and use it in `configure.in'.
+Other files that might need to be updated are:
+- `$ERL_TOP/xcomp/erl-xcomp-vars.sh'
+- `$ERL_TOP/erl-build-tool-vars.sh'
+- `$ERL_TOP/erts/aclocal.m4'
+- `$ERL_TOP/xcomp/README'
+- `$ERL_TOP/xcomp/erl-xcomp-*.conf'
+Note that this might be an incomplete list of files that need to be updated.
-The erl-xcomp.conf.template contains all available configuration variables
-and can be used as a template when creating a configuration. See the
-erl-xcomp-TileraMDE2.0-tilepro.conf for an example of a working configuration
-file.
+General information on how to submit patches can be found at:
+ http://wiki.github.com/erlang/otp/submitting-patches
-Instead of using the configuration files one can export the configuration
-variables as ordinary environment variables before calling otp_build. If
-default behavior of a variable is satisfactory, the variable need not to
-be set and exported.
+======= Build and Install =====================================================
-Note that the support for cross compiling is in its early stage of development,
-and should be considered as experimental. The build system including cross
-compilation configuration variables used may be subject to non backward
-compatible changes without prior notice. It works for cross compiling some
-Linux/GNU systems, but has only been partly tested for more esoteric platforms.
-The VxWorks example file is highly dependent on our environment and is here
-more or less only for internal use.
+ [1]
-Please submit any patches for cross compiling in a way consistent with this
-system. If a new configuration variable is needed for your system, add it to the
-template file, use it in otp_build, aclocal.m4 and/or configure.in. All input is
-welcome as we cannot possibly have all cross compiling environments out there to
-test with.
+Change directory into the top directory of the Erlang/OTP source tree.
-General information on how to submit patches can be found at:
- http://wiki.github.com/erlang/otp/submitting-patches
+ $ cd $ERL_TOP
+
+------- Build -----------------------------------------------------------------
+
+In order to compile Erlang code, a small Erlang bootstrap system has to be
+built, or an Erlang/OTP system of the same release as the one being built
+has to be provided in the `$PATH'. The Erlang/OTP for the target system will
+be built using this Erlang system, together with the cross compilation tools
+provided.
+
+If you want to build using a compatible Erlang/OTP system in the `$PATH',
+jump to [3].
+
+-- Building a bootstrap system --
+
+ [2]
+
+ $ ./configure --enable-bootstrap-only
+ $ make
+
+The `--enable-bootstrap-only' argument to `configure' isn't strictly necessary,
+but will speed things up. It will only run `configure' in applications
+necessary for the bootstrap, and will disable a lot of things not needed by
+the bootstrap system. If you run `configure' without `--enable-boostrap-only'
+you also have to run make as `make bootstrap'; otherwise, the whole system will
+be built.
+
+-- Cross building the system --
+
+ [3]
+
+ $ ./configure --build=<BUILD> --host=<HOST> [Other Configure Args]
+ $ make
+
+<BUILD> should equal the CPU-VENDOR-OS triplet of the system that you build
+on. If you execute `$ERL_TOP/erts/autoconf/config.guess', it will in most
+cases print the triplet you want to use for this.
+
+<HOST> is the system that you build for. It does not have to be a full
+CPU-VENDOR-OS triplet, but can be. The full CPU-VENDOR-OS triplet will be
+created by executing `$ERL_TOP/erts/autoconf/config.sub <HOST>'. If
+`config.sub' fails, you need to be more specific.
+
+Pass the cross compilation variables as command line arguments to `configure'
+using a `<VAR>=<VALUE>' syntax (or export them in the environment). Note that
+you can *not* pass a configuration file using `--xcomp-conf=<FILE>' when you
+invoke `configure' directly. The `--xcomp-conf=<FILE>' argument can only
+be passed to `$ERL_TOP/otp_build configure'.
+
+`make' will verify that the Erlang/OTP system used when building is of the
+same release as the system being built, and will fail if this is not the case.
+It is possible, however not recommended, to force the cross compilation even
+though the wrong Erlang/OTP system is used. This by invoking `make' like this:
+`make ERL_XCOMP_FORCE_DIFFERENT_OTP=yes'. Note that this build might fail,
+silently produce suboptimal code, or silently produce erroneous code.
+
+-- Installing --
+
+You can either install using the installation paths determined by `configure'
+[4], or install manually using [5].
+
+ [4]
+
+ $ make install DESTDIR=<TEMPORARY_PREFIX>
+
+`make install' will install at a location specified when doing `configure'.
+`configure' arguments specifying where the installation should reside are for
+example: `--prefix', `--exec-prefix', `--libdir', `--bindir', etc. By default
+it will install under `/usr/local'. You typically do not want to install your
+cross build under `/usr/local' on your build machine. Using `DESTDIR' will
+cause the installation paths to be prefixed by `$DESTDIR'. This makes it
+possible to install and package the installation on the build machine without
+having to place the installation in the same directory on the build machine as
+it should be executed from on the target machine.
+
+When `make install' has finished, change directory into `$DESTDIR', package
+the system, move it to the target machine, and unpack it. Note that the
+installation will only be working on the target machine at the location
+determined by `configure'.
+
+Installing manually:
+
+ [5]
+
+ $ make release RELEASE_ROOT=<RELEASE_DIR>
+
+`make release' will copy what you have built for the target machine to
+`<RELEASE_DIR>'. The `Install' script will not be run. The content of
+`<RELEASE_DIR>' is what by default ends up in `/usr/local/lib/erlang'.
-== Build and Install ===========================================================
+The `Install' script used when installing Erlang/OTP requires common Unix
+tools such as `sed' to be present in your `$PATH'. If your target system
+does not have such tools, you need to run the `Install' script on your
+build machine before packaging Erlang/OTP. The `Install' script should
+currently be invoked as follows in the directory where it resides
+(the top directory):
+ `./Install [-cross] [-minimal|-sasl] <ERL_ROOT>'
+ where:
+ -minimal - Creates an installation that starts up a minimal amount
+ of applications, i.e., only `kernel' and `stdlib' are
+ started. The minimal system is normally enough.
+ -sasl - Creates an installation that also starts up the `sasl'
+ application.
+ -cross - For cross compilation. Informs the install script that it
+ is run on the build machine.
+ <ERL_ROOT> - The absolute path to the Erlang installation to use at run
+ time. This is often the same as the current working
+ directory, but does not have to be. It can follow any other
+ path through the file system to the same directory.
+If neither `-minimal', nor `-sasl' is passed as argument you will be
+prompted.
- [1] $ cd $ERL_TOP
+You can now either:
-Either set up your cross compilation variables in the environment manually,
-or set up the environment using a configuration file by executing:
- [2] $ eval `./otp_build env_cross <ABSOLUTE_PATH_TO_XCONF_FILE>`
+ [6]
-Configure and build Erlang/OTP:
- [3] $ ./otp_build configure
- [4] $ ./otp_build boot -a
- [5] $ ./otp_build release -a <ABSOLUTE_PATH_TO_RELEASE_ROOT>
+* Decide where the installation should be located on the target machine, run
+ the `Install' script on the build machine, and package the installed
+ installation. The installation just need to be unpacked at the right
+ location on the target machine:
-The Install script used when installing Erlang/OTP requires common Unix
-tools such as 'sed' to be present in your PATH. If your target system
-does not have such tools, you need to run the Install script on your
-build machine before packing Erlang/OTP. If so, run the Install script
-like follows; otherwise skip [6] and [7]:
- [6] $ cd <ABSOLUTE_PATH_TO_RELEASE_ROOT>
- [7] $ ./Install -cross <ABSOLUTE_INSTALL_ROOT_ON_TARGET> # answer questions
+ $ cd <RELEASE_DIR>
+ $ ./Install -cross [-minimal|-sasl] <ABSOLUTE_INSTALL_DIR_ON_TARGET>
-Pack Erlang/OTP as follows (gnu tar is assumed):
- [8] $ cd <ABSOLUTE_PATH_TO_RELEASE_ROOT>
- [9] $ tar -zcf <WHERE_TO_SAVE_THE_RELEASE>/<RELEASE_NAME>.tar.gz *
+ [7]
-Install Erlang/OTP on the target system like follows. If you ran the Install
-script before packing ([6] and [7]) you should skip [12]:
- [10] $ cd <ABSOLUTE_INSTALL_ROOT_ON_TARGET>
- [11] $ tar -zxf <WHERE_THE_PACKED_RELEASE_EXIST>/<RELEASE_NAME>.tar.gz
- [12] $ ./Install <ABSOLUTE_INSTALL_ROOT_ON_TARGET> # answer questions
+* Package the installation in <RELEASE_DIR>, place it wherever you want on
+ your target machine, and run the `Install' script on your target machine:
-<ABSOLUTE_INSTALL_ROOT_ON_TARGET> usually equals current working directory
-when you run the Install script on the target system, but does not have to.
-It can follow another path through the file system to the same directory.
-<ABSOLUTE_INSTALL_ROOT_ON_TARGET> is the path that will be used when running
-Erlang/OTP and is the path that have to be available at run time.
+ $ cd <ABSOLUTE_INSTALL_DIR_ON_TARGET>
+ $ ./Install [-minimal|-sasl] <ABSOLUTE_INSTALL_DIR_ON_TARGET>
-== Currently used configuration variables ======================================
+-- Building with the `otp_build' script --
--- Mandatory -------------------------------------------------------------------
+ [8]
-* erl_xcomp_host
- Target system. The value will be passed as '--host' argument to the configure
- script. It does not have to be a full CPU-VENDOR-OS triplet, but can be. The
- full CPU-VENDOR-OS triplet will be created by:
- $ERL_TOP/erts/autoconf/config.sub $erl_xcomp_host
+ $ cd $ERL_TOP
--- Optional --------------------------------------------------------------------
+ [9]
-* erl_xcomp_configure_flags
- To override the configure flags for a special target system, you
- can set this variable which overrides configure parameters on the
- command line and instead uses the specified options. The variable
- leaves the build-host system untouched.
+ $ ./otp_build configure [--build=<BUILD>] [--host=<HOST>] \
+ [--with-xcomp-conf=<FILE>] [Other Configure Args]
--- Optional build environment flags --
+If you have your cross compilation configuration in a file, pass it using the
+`--xcomp-conf=<FILE>' command line argument. If not, pass the configuration
+variables on the command line using a `<VAR>=<VALUE>' syntax (or in the
+environment).
-If the cross compilation tools aren't prefixed by '$erl_xcomp_host-',
-you will have to use these configuration variables in order to use the
-right cross compilation tools.
+`--build=<BUILD>', and `--host=<HOST>' are the same as described at [3].
+The `--xcomp-conf=<FILE>' argument causes `otp_build' to read the cross
+compilation configuration from `<FILE>'. All of these arguments are in this
+case optional, but `<BUILD>', and `<HOST>' must be given either by passing
+`--build=<BUILD>' and `--host=<HOST>' on the command line, or by setting
+`erl_xcomp_build=<HOST>', and `erl_xcomp_host=<HOST>' in `<FILE>' and
+passing the `--xcomp-conf=<FILE>' argument.
-* erl_xcomp_cc
- C compiler.
+`otp_build configure' will configure both for the boostrap system on the
+build machine and the cross host system.
-* erl_xcomp_ld
- Linker.
+ [10]
-* erl_xcomp_cflags
- C compiler flags.
+ $ ./otp_build boot -a
-* erl_xcomp_cpp
- C pre processor.
+ 'otp_build boot -a' will first build a bootstrap system
+for the build machine and then do the cross build of the system.
-* erl_xcomp_ldflags
- Linker flags.
+ [11]
-* erl_xcomp_ranlib
- Ranlib program.
+ $ ./otp_build release -a <RELEASE_DIR>
-* erl_xcomp_ar
- Ar program.
+'otp_build release -a' will do the same as [5], and you will after this have
+to do a manual install either by doing [6], or [7].
-* erl_xcomp_ded_ld
- Dynamic Erlang Driver linker.
+======== Currently used configuration variables ===============================
-* erl_xcomp_ded_ldflags
- Dynamic Erlang Driver linker flags.
+Note that you cannot define arbitrary variables in a cross compilation
+configuration file. Only the ones listed below will be guaranteed to be
+visible throughout the whole execution of all `configure' scripts. Other
+variables needs to be defined as arguments to `configure' or exported in
+the environment.
-* erl_xcomp_ded_ld_runtime_library_path
- Dynamic Erlang Driver runtime linker path.
+-------- `otp_build' only variables -------------------------------------------
--- Optional feature, or bug tests --
+Variables in this section are only used, when configuring Erlang/OTP for
+cross compilation using `$ERL_TOP/otp_build configure'.
+
+NOTE! These variables currently have *no* effect if you configure using the
+`configure' script directly.
+
+* erl_xcomp_build - Build system.
+ This value will be passed as `--build=$erl_xcomp_build' argument to the
+ `configure' script. It does not have to be a full CPU-VENDOR-OS triplet,
+ but can be. The full CPU-VENDOR-OS triplet will be created by:
+ `$ERL_TOP/erts/autoconf/config.sub $erl_xcomp_build'
+ If `erl_xcomp_build=guess', the build system will be guessed using:
+ `$ERL_TOP/erts/autoconf/config.guess'.
+
+* erl_xcomp_host - Cross host system.
+ This value will be passed as `--host=$erl_xcomp_host' argument to the
+ `configure' script. It does not have to be a full CPU-VENDOR-OS triplet,
+ but can be. The full CPU-VENDOR-OS triplet will be created by:
+ `$ERL_TOP/erts/autoconf/config.sub $erl_xcomp_host'
+
+* erl_xcomp_configure_flags - Extra configure flags.
+ Extra flags to pass to the `configure' script.
+
+-------- Cross compiler and other tools to use --------------------------------
+
+If the cross compilation tools are prefixed by `<HOST>-' you probably do
+not need to set these variables (where `<HOST>' is what has been passed as
+`--host=<HOST>' argument to `configure').
+
+* CC - C compiler.
+
+* CFLAGS - C compiler flags.
+
+* STATIC_CFLAGS - Static C compiler flags.
+
+* CFLAG_RUNTIME_LIBRARY_PATH - C compiler runtime library path flag.
+ This flag should set a specific runtime library path for the shared
+ library at link time. Note that this is actually a linker flag, but it
+ needs to be passed via the compiler.
+
+* CPP - C pre-processor.
+
+* CPPFLAGS - C pre-processor flags.
+
+* CXX - C++ compiler.
+
+* CXXFLAGS - C++ compiler flags.
+
+* LD - Linker
+
+* LDFLAGS - Linker flags.
+
+-- Dynamic Erlang Driver linker flags. --
+
+NOTE! Either define all or non of the DED_LD* variables.
+
+* DED_LD - Linker.
+
+* DED_LDFLAGS - Linker flags.
+
+* DED_LD_FLAG_RUNTIME_LIBRARY_PATH - Linker runtime library path flag.
+ This flag should set a specific runtime library path for the shared
+ library at link time.
+
+-- Other tools --
+
+* RANLIB - ranlib
+
+* AR - ar
+
+-------- Cross System Root Locations ------------------------------------------
+
+* erl_xcomp_sysroot - Absolute cross system root path.
+ The absolute path to the system root of the cross compilation
+ environment. Currently, the `crypto', `odbc', `ssh' and `ssl'
+ applications need the system root. These applications will be skipped
+ if the system root has not been set. The system root might be needed
+ for other things too. If this is the case and the system root has not
+ been set, `configure' will fail and request you to set it.
+
+* erl_xcomp_isysroot - Absolute cross include system root path.
+ The absolute path to the system root for includes of the cross
+ compilation environment. If not set, this value defaults to
+ `$erl_xcomp_sysroot', i.e., only set this value if the include system
+ root path is not the same as the system root path.
+
+-------- Optional feature, or bug tests ---------------------------------------
These tests cannot (always) be done automatically when cross compiling. You
usually does not need to set these variables. Only set these if you really
know what you are doing.
+The `configure' script will issue a warning when a default value is used.
+When a variable has been set, no warning will be issued.
+
* erl_xcomp_bigendian - yes|no
- If yes, the target system must be big endian. If no, little endian. This can
- often be automatically detected, but not always. If not automatically
- detected, configure will fail unless this variable is set. No default value
- is used, i.e., configure will try to figure this out automatically.
-
-* erl_xcomp_linux_clock_gettime_correction - yes|no (defaults to yes)
- If yes, clock_gettime(CLOCK_MONOTONIC, _) on the target system must work.
- This variable is recommended to be set to no on Linux systems with kernel
- versions less than 2.6.
-
-* erl_xcomp_linux_nptl - yes|no (defaults to yes on Linux; otherwise, no)
- If yes, the target system must have NPTL (Native POSIX Thread Library).
- Older Linux systems have LinuxThreads instead of NPTL (Linux kernel
- versions typically less than 2.6).
-
-* erl_xcomp_linux_usable_sigusrx - yes|no (defaults to yes)
- If yes, the SIGUSR1 and SIGUSR2 must be usable by the ERTS. Old
- LinuxThreads thread libraries (Linux kernel versions less than 2.2) used
- these signals and made them unusable by the ERTS.
-
-* erl_xcomp_linux_usable_sigaltstack - yes|no (defaults to yes)
- If yes, sigaltstack() must be usable on the target system. sigaltstack()
- on Linux kernel versions less than 2.4 are broken.
-
-* erl_xcomp_poll - yes|no (defaults to no on Darwin/MacOSX; otherwise, yes)
- If yes, the target system must have a working poll() implementation that also
- can handle devices. If no, select() will be used instead of poll().
-
-* erl_xcomp_kqueue - yes|no (defaults to no)
- If yes, the target system must have a working kqueue() implementation that
- returns a file descriptor which can be used by poll() and/or select().
- If no and the target system has not got epoll() or /dev/poll, the kernel-poll
- feature will be disabled.
-
-* erl_xcomp_putenv_copy - yes|no (defaults to no)
- If yes, the target system must have a putenv() implementation that stores a
- copy of the key/value pair.
-
-* erl_xcomp_reliable_fpe - yes|no (defaults to no)
- If yes, the target system must have reliable floating point exceptions.
-
-* erl_xcomp_getaddrinfo - yes|no (defaults to no)
- If yes, the target system must have a working getaddrinfo() implementation
- that can handle both IPv4 and IPv6.
-
-* erl_xcomp_gethrvtime_procfs_ioctl - yes|no (defaults to no)
- If yes, the target system must have a working gethrvtime() implementation
- and is used with procfs ioctl().
-
-* erl_xcomp_clock_gettime - yes|no (defaults to no)
- If yes, the target system must have a working clock_gettime() implementation
- that can be used for retrieving process CPU time.
-
-* erl_xcomp_after_morecore_hook - yes|no (defaults to no)
- If yes, the target system must have a working __after_morecore_hook that can
- be used for tracking used malloc() implementations core memory usage.
-
-* erl_xcomp_dlsym_brk_wrappers - yes|no (defaults to no)
- If yes, the target system must have a working dlsym(RTLD_NEXT, <S>)
- implementation that can be used on 'brk' and 'sbrk' symbols used by the
- malloc() implementation in use, and by this track the malloc() implementations
- core memory usage.
-
-================================================================================
+ If `yes', the target system must be big endian. If `no', little endian.
+ This can often be automatically detected, but not always. If not
+ automatically detected, `configure' will fail unless this variable is
+ set. No default value is used, i.e., `configure' will try to figure
+ this out automatically.
+
+* erl_xcomp_linux_clock_gettime_correction - yes|no (defaults to `yes' on
+ Linux; otherwise, `no')
+ If `yes', `clock_gettime(CLOCK_MONOTONIC, _)' on the target system must
+ work. This variable is recommended to be set to `no' on Linux systems
+ with kernel versions less than 2.6.
+
+* erl_xcomp_linux_nptl - yes|no (defaults to `yes' on Linux; otherwise, `no')
+ If `yes', the target system must have NPTL (Native POSIX Thread Library).
+ Older Linux systems have LinuxThreads instead of NPTL (Linux kernel
+ versions typically less than 2.6).
+
+* erl_xcomp_linux_usable_sigusrx - yes|no (defaults to `yes')
+ If `yes', the `SIGUSR1' and `SIGUSR2' signals must be usable by the ERTS.
+ Old LinuxThreads thread libraries (Linux kernel versions less than 2.2)
+ used these signals and made them unusable by the ERTS.
+
+* erl_xcomp_linux_usable_sigaltstack - yes|no (defaults to `yes' on Linux;
+ otherwise, `no')
+ If `yes', `sigaltstack()' must be usable on the target system.
+ `sigaltstack()' on Linux kernel versions less than 2.4 are broken.
+
+* erl_xcomp_poll - yes|no (defaults to `no' on Darwin/MacOSX; otherwise, `yes')
+ If `yes', the target system must have a working `poll()' implementation
+ that also can handle devices. If `no', `select()' will be used instead of
+ `poll()'.
+
+* erl_xcomp_kqueue - yes|no (defaults to `no')
+ If `yes', the target system must have a working `kqueue()' implementation
+ that returns a file descriptor which can be used by `poll()' and/or
+ `select()'. If `no' and the target system has not got `epoll()' or
+ `/dev/poll', the kernel-poll feature will be disabled.
+
+* erl_xcomp_putenv_copy - yes|no (defaults to `no')
+ If `yes', the target system must have a `putenv()' implementation that
+ stores a copy of the key/value pair.
+
+* erl_xcomp_reliable_fpe - yes|no (defaults to `no')
+ If `yes', the target system must have reliable floating point exceptions.
+
+* erl_xcomp_getaddrinfo - yes|no (defaults to `no')
+ If `yes', the target system must have a working `getaddrinfo()'
+ implementation that can handle both IPv4 and IPv6.
+
+* erl_xcomp_gethrvtime_procfs_ioctl - yes|no (defaults to `no')
+ If `yes', the target system must have a working `gethrvtime()'
+ implementation and is used with procfs `ioctl()'.
+
+* erl_xcomp_clock_gettime_cpu_time - yes|no (defaults to `no')
+ If `yes', the target system must have a working `clock_gettime()'
+ implementation that can be used for retrieving process CPU time.
+
+* erl_xcomp_after_morecore_hook - yes|no (defaults to `no')
+ If `yes', the target system must have a working `__after_morecore_hook'
+ that can be used for tracking used `malloc()' implementations core memory
+ usage.
+
+* erl_xcomp_dlsym_brk_wrappers - yes|no (defaults to `no')
+ If `yes', the target system must have a working `dlsym(RTLD_NEXT, <S>)'
+ implementation that can be used on `brk' and `sbrk' symbols used by the
+ `malloc()' implementation in use, and by this track the `malloc()'
+ implementations core memory usage.
+
+===============================================================================