OTP-8323 Cross compilation improvements and other build system

          improvements.

          Most notable:

          Lots of cross compilation improvements. The old cross compilation
          support was more or less non-existing as well as broken. Please,
          note that the cross compilation support should still be
          considered as experimental. Also note that old cross compilation
          configurations cannot be used without modifications. For more
          information on cross compiling Erlang/OTP see the
          $ERL_TOP/xcomp/README file.

          Support for staged install using <url
          href="http://www.gnu.org/prep/standards/html_node/DESTDIR.html">D
          ESTDIR</url>. The old broken INSTALL_PREFIX has also been fixed.
          For more information see the $ERL_TOP/README file.

          Documentation of the release target of the top Makefile. For more
          information see the $ERL_TOP/README file.

          make install now by default creates relative symbolic links
          instead of absolute ones. For more information see the
          $ERL_TOP/README file.

          $ERL_TOP/configure --help=recursive now works and prints help for
          all applications with configure scripts.

          Doing make install, or make release directly after make all no
          longer triggers miscellaneous rebuilds.

          Existing bootstrap system is now used when doing make install, or
          make release without a preceding make all.

          The crypto and ssl applications use the same runtime library path
          when dynamically linking against libssl.so and libcrypto.so. The
          runtime library search path has also been extended.

          The configure scripts of erl_interface and odbc now search for
          thread libraries and thread library quirks the same way as erts
          do.

          The configure script of the odbc application now also looks for
          odbc libraries in lib64 and lib/64 directories when building on a
          64-bit system.

          The config.h.in file in the erl_interface application is now
          automatically generated in instead of statically updated which
          reduces the risk of configure tests without any effect.

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.
+
+===============================================================================