fix ya.make

1 files changed, 0 insertions, 1567 deletions

diff --git a/contrib/libs/postgresql/INSTALL b/contrib/libs/postgresql/INSTALL
deleted file mode 100644
index 3230fe7715b..00000000000
--- a/contrib/libs/postgresql/INSTALL
+++ /dev/null
@@ -1,1567 +0,0 @@
-PostgreSQL Installation from Source Code
-
-------------------------------------------------------------------------
-
-This document describes the installation of PostgreSQL using this source
-code distribution.
-
-If you are building PostgreSQL for Microsoft Windows, read this document
-if you intend to build with MinGW or Cygwin; but if you intend to build
-with Microsoft's Visual C++, see the main documentation instead.
-
-------------------------------------------------------------------------
-
-Short Version
-
-    ./configure
-    make
-    su
-    make install
-    adduser postgres
-    mkdir /usr/local/pgsql/data
-    chown postgres /usr/local/pgsql/data
-    su - postgres
-    /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
-    /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
-    /usr/local/pgsql/bin/createdb test
-    /usr/local/pgsql/bin/psql test
-
-The long version is the rest of this document.
-
-------------------------------------------------------------------------
-
-Requirements
-
-In general, a modern Unix-compatible platform should be able to run
-PostgreSQL. The platforms that had received specific testing at the time
-of release are described in the section called "Supported Platforms"
-below.
-
-The following software packages are required for building PostgreSQL:
-
--   GNU make version 3.80 or newer is required; other make programs or
-    older GNU make versions will *not* work. (GNU make is sometimes
-    installed under the name "gmake".) To test for GNU make enter:
-
-        make --version
-
--   You need an ISO/ANSI C compiler (at least C99-compliant). Recent
-    versions of GCC are recommended, but PostgreSQL is known to build
-    using a wide variety of compilers from different vendors.
-
--   tar is required to unpack the source distribution, in addition to
-    either gzip or bzip2.
-
--   The GNU Readline library is used by default. It allows psql (the
-    PostgreSQL command line SQL interpreter) to remember each command
-    you type, and allows you to use arrow keys to recall and edit
-    previous commands. This is very helpful and is strongly recommended.
-    If you don't want to use it then you must specify the
-    "--without-readline" option to "configure". As an alternative, you
-    can often use the BSD-licensed "libedit" library, originally
-    developed on NetBSD. The "libedit" library is GNU
-    Readline-compatible and is used if "libreadline" is not found, or if
-    "--with-libedit-preferred" is used as an option to "configure". If
-    you are using a package-based Linux distribution, be aware that you
-    need both the readline and readline-devel packages, if those are
-    separate in your distribution.
-
--   The zlib compression library is used by default. If you don't want
-    to use it then you must specify the "--without-zlib" option to
-    "configure". Using this option disables support for compressed
-    archives in pg_dump and pg_restore.
-
-The following packages are optional. They are not required in the
-default configuration, but they are needed when certain build options
-are enabled, as explained below:
-
--   To build the server programming language PL/Perl you need a full
-    Perl installation, including the "libperl" library and the header
-    files. The minimum required version is Perl 5.8.3. Since PL/Perl
-    will be a shared library, the "libperl" library must be a shared
-    library also on most platforms. This appears to be the default in
-    recent Perl versions, but it was not in earlier versions, and in any
-    case it is the choice of whomever installed Perl at your site.
-    "configure" will fail if building PL/Perl is selected but it cannot
-    find a shared "libperl". In that case, you will have to rebuild and
-    install Perl manually to be able to build PL/Perl. During the
-    configuration process for Perl, request a shared library.
-
-    If you intend to make more than incidental use of PL/Perl, you
-    should ensure that the Perl installation was built with the
-    usemultiplicity option enabled (perl -V will show whether this is
-    the case).
-
--   To build the PL/Python server programming language, you need a
-    Python installation with the header files and the sysconfig module.
-    The minimum required version is Python 2.7. Python 3 is supported if
-    it's version 3.2 or later; but see the PL/Python documentation when
-    using Python 3.
-
-    Since PL/Python will be a shared library, the "libpython" library
-    must be a shared library also on most platforms. This is not the
-    case in a default Python installation built from source, but a
-    shared library is available in many operating system distributions.
-    "configure" will fail if building PL/Python is selected but it
-    cannot find a shared "libpython". That might mean that you either
-    have to install additional packages or rebuild (part of) your Python
-    installation to provide this shared library. When building from
-    source, run Python's configure with the --enable-shared flag.
-
--   To build the PL/Tcl procedural language, you of course need a Tcl
-    installation. The minimum required version is Tcl 8.4.
-
--   To enable Native Language Support (NLS), that is, the ability to
-    display a program's messages in a language other than English, you
-    need an implementation of the Gettext API. Some operating systems
-    have this built-in (e.g., Linux, NetBSD, Solaris), for other systems
-    you can download an add-on package from
-    https://www.gnu.org/software/gettext/. If you are using the Gettext
-    implementation in the GNU C library then you will additionally need
-    the GNU Gettext package for some utility programs. For any of the
-    other implementations you will not need it.
-
--   You need OpenSSL, if you want to support encrypted client
-    connections. OpenSSL is also required for random number generation
-    on platforms that do not have "/dev/urandom" (except Windows). The
-    minimum version required is 1.0.1.
-
--   You need Kerberos, OpenLDAP, and/or PAM, if you want to support
-    authentication using those services.
-
--   You need LZ4, if you want to support compression of data with this
-    method; see the configuration parameter default_toast_compression.
-
--   To build the PostgreSQL documentation, there is a separate set of
-    requirements; see the main documentation's appendix on
-    documentation.
-
-If you are building from a Git tree instead of using a released source
-package, or if you want to do server development, you also need the
-following packages:
-
--   Flex and Bison are needed to build from a Git checkout, or if you
-    changed the actual scanner and parser definition files. If you need
-    them, be sure to get Flex 2.5.31 or later and Bison 1.875 or later.
-    Other lex and yacc programs cannot be used.
-
--   Perl 5.8.3 or later is needed to build from a Git checkout, or if
-    you changed the input files for any of the build steps that use Perl
-    scripts. If building on Windows you will need Perl in any case. Perl
-    is also required to run some test suites.
-
-If you need to get a GNU package, you can find it at your local GNU
-mirror site (see https://www.gnu.org/prep/ftp for a list) or at
-ftp://ftp.gnu.org/gnu/.
-
-Also check that you have sufficient disk space. You will need about 350
-MB for the source tree during compilation and about 60 MB for the
-installation directory. An empty database cluster takes about 40 MB;
-databases take about five times the amount of space that a flat text
-file with the same data would take. If you are going to run the
-regression tests you will temporarily need up to an extra 300 MB. Use
-the "df" command to check free disk space.
-
-------------------------------------------------------------------------
-
-Installation Procedure
-
-1.  Configuration
-
-    The first step of the installation procedure is to configure the
-    source tree for your system and choose the options you would like.
-    This is done by running the "configure" script. For a default
-    installation simply enter:
-
-        ./configure
-
-    This script will run a number of tests to determine values for
-    various system dependent variables and detect any quirks of your
-    operating system, and finally will create several files in the build
-    tree to record what it found.
-
-    You can also run "configure" in a directory outside the source tree,
-    and then build there, if you want to keep the build directory
-    separate from the original source files. This procedure is called a
-    VPATH build. Here's how:
-
-        mkdir build_dir
-        cd build_dir
-        /path/to/source/tree/configure [options go here]
-        make
-
-    The default configuration will build the server and utilities, as
-    well as all client applications and interfaces that require only a C
-    compiler. All files will be installed under "/usr/local/pgsql" by
-    default.
-
-    You can customize the build and installation process by supplying
-    one or more command line options to "configure". Typically you would
-    customize the install location, or the set of optional features that
-    are built. "configure" has a large number of options, which are
-    described in the section called "configure Options".
-
-    Also, "configure" responds to certain environment variables, as
-    described in the section called "configure Environment Variables".
-    These provide additional ways to customize the configuration.
-
-2.  Build
-
-    To start the build, type either of:
-
-        make
-        make all
-
-    (Remember to use GNU make.) The build will take a few minutes
-    depending on your hardware.
-
-    If you want to build everything that can be built, including the
-    documentation (HTML and man pages), and the additional modules
-    ("contrib"), type instead:
-
-        make world
-
-    If you want to build everything that can be built, including the
-    additional modules ("contrib"), but without the documentation, type
-    instead:
-
-        make world-bin
-
-    If you want to invoke the build from another makefile rather than
-    manually, you must unset MAKELEVEL or set it to zero, for instance
-    like this:
-
-        build-postgresql:
-                $(MAKE) -C postgresql MAKELEVEL=0 all
-
-    Failure to do that can lead to strange error messages, typically
-    about missing header files.
-
-3.  Regression Tests
-
-    If you want to test the newly built server before you install it,
-    you can run the regression tests at this point. The regression tests
-    are a test suite to verify that PostgreSQL runs on your machine in
-    the way the developers expected it to. Type:
-
-        make check
-
-    (This won't work as root; do it as an unprivileged user.) See the
-    file "src/test/regress/README" and the documentation for detailed
-    information about interpreting the test results. You can repeat this
-    test at any later time by issuing the same command.
-
-4.  Installing the Files
-
-    Note:
-
-    If you are upgrading an existing system be sure to read the
-    documentation, which has instructions about upgrading a cluster.
-
-    To install PostgreSQL enter:
-
-        make install
-
-    This will install files into the directories that were specified in
-    Step 1. Make sure that you have appropriate permissions to write
-    into that area. Normally you need to do this step as root.
-    Alternatively, you can create the target directories in advance and
-    arrange for appropriate permissions to be granted.
-
-    To install the documentation (HTML and man pages), enter:
-
-        make install-docs
-
-    If you built the world above, type instead:
-
-        make install-world
-
-    This also installs the documentation.
-
-    If you built the world without the documentation above, type
-    instead:
-
-        make install-world-bin
-
-    You can use make install-strip instead of make install to strip the
-    executable files and libraries as they are installed. This will save
-    some space. If you built with debugging support, stripping will
-    effectively remove the debugging support, so it should only be done
-    if debugging is no longer needed. install-strip tries to do a
-    reasonable job saving space, but it does not have perfect knowledge
-    of how to strip every unneeded byte from an executable file, so if
-    you want to save all the disk space you possibly can, you will have
-    to do manual work.
-
-    The standard installation provides all the header files needed for
-    client application development as well as for server-side program
-    development, such as custom functions or data types written in C.
-
-    Client-only installation:  If you want to install only the client
-    applications and interface libraries, then you can use these
-    commands:
-
-        make -C src/bin install
-        make -C src/include install
-        make -C src/interfaces install
-        make -C doc install
-
-    "src/bin" has a few binaries for server-only use, but they are
-    small.
-
-Uninstallation:  To undo the installation use the command "make
-uninstall". However, this will not remove any created directories.
-
-Cleaning:  After the installation you can free disk space by removing
-the built files from the source tree with the command "make clean". This
-will preserve the files made by the "configure" program, so that you can
-rebuild everything with "make" later on. To reset the source tree to the
-state in which it was distributed, use "make distclean". If you are
-going to build for several platforms within the same source tree you
-must do this and re-configure for each platform. (Alternatively, use a
-separate build tree for each platform, so that the source tree remains
-unmodified.)
-
-If you perform a build and then discover that your "configure" options
-were wrong, or if you change anything that "configure" investigates (for
-example, software upgrades), then it's a good idea to do "make
-distclean" before reconfiguring and rebuilding. Without this, your
-changes in configuration choices might not propagate everywhere they
-need to.
-
-------------------------------------------------------------------------
-
-configure Options
-
-"configure"'s command line options are explained below. This list is not
-exhaustive (use ./configure --help to get one that is). The options not
-covered here are meant for advanced use-cases such as cross-compilation,
-and are documented in the standard Autoconf documentation.
-
-------------------------------------------------------------------------
-
-Installation Locations
-
-These options control where make install will put the files. The
-"--prefix" option is sufficient for most cases. If you have special
-needs, you can customize the installation subdirectories with the other
-options described in this section. Beware however that changing the
-relative locations of the different subdirectories may render the
-installation non-relocatable, meaning you won't be able to move it after
-installation. (The man and doc locations are not affected by this
-restriction.) For relocatable installs, you might want to use the
---disable-rpath option described later.
-
---prefix=PREFIX
-
-    Install all files under the directory "PREFIX" instead of
-    "/usr/local/pgsql". The actual files will be installed into various
-    subdirectories; no files will ever be installed directly into the
-    "PREFIX" directory.
-
---exec-prefix=EXEC-PREFIX
-
-    You can install architecture-dependent files under a different
-    prefix, "EXEC-PREFIX", than what "PREFIX" was set to. This can be
-    useful to share architecture-independent files between hosts. If you
-    omit this, then "EXEC-PREFIX" is set equal to "PREFIX" and both
-    architecture-dependent and independent files will be installed under
-    the same tree, which is probably what you want.
-
---bindir=DIRECTORY
-
-    Specifies the directory for executable programs. The default is
-    "EXEC-PREFIX/bin", which normally means "/usr/local/pgsql/bin".
-
---sysconfdir=DIRECTORY
-
-    Sets the directory for various configuration files, "PREFIX/etc" by
-    default.
-
---libdir=DIRECTORY
-
-    Sets the location to install libraries and dynamically loadable
-    modules. The default is "EXEC-PREFIX/lib".
-
---includedir=DIRECTORY
-
-    Sets the directory for installing C and C++ header files. The
-    default is "PREFIX/include".
-
---datarootdir=DIRECTORY
-
-    Sets the root directory for various types of read-only data files.
-    This only sets the default for some of the following options. The
-    default is "PREFIX/share".
-
---datadir=DIRECTORY
-
-    Sets the directory for read-only data files used by the installed
-    programs. The default is "DATAROOTDIR". Note that this has nothing
-    to do with where your database files will be placed.
-
---localedir=DIRECTORY
-
-    Sets the directory for installing locale data, in particular message
-    translation catalog files. The default is "DATAROOTDIR/locale".
-
---mandir=DIRECTORY
-
-    The man pages that come with PostgreSQL will be installed under this
-    directory, in their respective "manx" subdirectories. The default is
-    "DATAROOTDIR/man".
-
---docdir=DIRECTORY
-
-    Sets the root directory for installing documentation files, except
-    "man" pages. This only sets the default for the following options.
-    The default value for this option is "DATAROOTDIR/doc/postgresql".
-
---htmldir=DIRECTORY
-
-    The HTML-formatted documentation for PostgreSQL will be installed
-    under this directory. The default is "DATAROOTDIR".
-
-Note:
-
-Care has been taken to make it possible to install PostgreSQL into
-shared installation locations (such as "/usr/local/include") without
-interfering with the namespace of the rest of the system. First, the
-string "/postgresql" is automatically appended to datadir, sysconfdir,
-and docdir, unless the fully expanded directory name already contains
-the string "postgres" or "pgsql". For example, if you choose
-"/usr/local" as prefix, the documentation will be installed in
-"/usr/local/doc/postgresql", but if the prefix is "/opt/postgres", then
-it will be in "/opt/postgres/doc". The public C header files of the
-client interfaces are installed into includedir and are namespace-clean.
-The internal header files and the server header files are installed into
-private directories under includedir. See the documentation of each
-interface for information about how to access its header files. Finally,
-a private subdirectory will also be created, if appropriate, under
-libdir for dynamically loadable modules.
-
-------------------------------------------------------------------------
-
-PostgreSQL Features
-
-The options described in this section enable building of various
-PostgreSQL features that are not built by default. Most of these are
-non-default only because they require additional software, as described
-in the section called "Requirements".
-
---enable-nls[=LANGUAGES]
-
-    Enables Native Language Support (NLS), that is, the ability to
-    display a program's messages in a language other than English.
-    "LANGUAGES" is an optional space-separated list of codes of the
-    languages that you want supported, for example --enable-nls='de fr'.
-    (The intersection between your list and the set of actually provided
-    translations will be computed automatically.) If you do not specify
-    a list, then all available translations are installed.
-
-    To use this option, you will need an implementation of the Gettext
-    API.
-
---with-perl
-
-    Build the PL/Perl server-side language.
-
---with-python
-
-    Build the PL/Python server-side language.
-
---with-tcl
-
-    Build the PL/Tcl server-side language.
-
---with-tclconfig=DIRECTORY
-
-    Tcl installs the file "tclConfig.sh", which contains configuration
-    information needed to build modules interfacing to Tcl. This file is
-    normally found automatically at a well-known location, but if you
-    want to use a different version of Tcl you can specify the directory
-    in which to look for "tclConfig.sh".
-
---with-icu
-
-    Build with support for the ICU library, enabling use of ICU
-    collation features. This requires the ICU4C package to be installed.
-    The minimum required version of ICU4C is currently 4.2.
-
-    By default, pkg-config will be used to find the required compilation
-    options. This is supported for ICU4C version 4.6 and later. For
-    older versions, or if pkg-config is not available, the variables
-    ICU_CFLAGS and ICU_LIBS can be specified to "configure", like in
-    this example:
-
-        ./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-L/some/where/lib -licui18n -licuuc -licudata'
-
-    (If ICU4C is in the default search path for the compiler, then you
-    still need to specify nonempty strings in order to avoid use of
-    pkg-config, for example, ICU_CFLAGS=' '.)
-
---with-llvm
-
-    Build with support for LLVM based JIT compilation. This requires the
-    LLVM library to be installed. The minimum required version of LLVM
-    is currently 3.9.
-
-    "llvm-config" will be used to find the required compilation options.
-    "llvm-config", and then "llvm-config-$major-$minor" for all
-    supported versions, will be searched for in your PATH. If that would
-    not yield the desired program, use LLVM_CONFIG to specify a path to
-    the correct "llvm-config". For example
-
-        ./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'
-
-    LLVM support requires a compatible "clang" compiler (specified, if
-    necessary, using the CLANG environment variable), and a working C++
-    compiler (specified, if necessary, using the CXX environment
-    variable).
-
---with-lz4
-
-    Build with LZ4 compression support. This allows the use of LZ4 for
-    compression of table data.
-
---with-ssl=LIBRARY 
-
-    Build with support for SSL (encrypted) connections. The only
-    "LIBRARY" supported is "openssl". This requires the OpenSSL package
-    to be installed. "configure" will check for the required header
-    files and libraries to make sure that your OpenSSL installation is
-    sufficient before proceeding.
-
---with-openssl
-
-    Obsolete equivalent of --with-ssl=openssl.
-
---with-gssapi
-
-    Build with support for GSSAPI authentication. On many systems, the
-    GSSAPI system (usually a part of the Kerberos installation) is not
-    installed in a location that is searched by default (e.g.,
-    "/usr/include", "/usr/lib"), so you must use the options
-    "--with-includes" and "--with-libraries" in addition to this option.
-    "configure" will check for the required header files and libraries
-    to make sure that your GSSAPI installation is sufficient before
-    proceeding.
-
---with-ldap
-
-    Build with LDAP support for authentication and connection parameter
-    lookup (see the documentation about client authentication and libpq
-    for more information). On Unix, this requires the OpenLDAP package
-    to be installed. On Windows, the default WinLDAP library is used.
-    "configure" will check for the required header files and libraries
-    to make sure that your OpenLDAP installation is sufficient before
-    proceeding.
-
---with-pam
-
-    Build with PAM (Pluggable Authentication Modules) support.
-
---with-bsd-auth
-
-    Build with BSD Authentication support. (The BSD Authentication
-    framework is currently only available on OpenBSD.)
-
---with-systemd
-
-    Build with support for systemd service notifications. This improves
-    integration if the server is started under systemd but has no impact
-    otherwise. libsystemd and the associated header files need to be
-    installed to use this option.
-
---with-bonjour
-
-    Build with support for Bonjour automatic service discovery. This
-    requires Bonjour support in your operating system. Recommended on
-    macOS.
-
---with-uuid=LIBRARY
-
-    Build the uuid-ossp module (which provides functions to generate
-    UUIDs), using the specified UUID library. "LIBRARY" must be one of:
-
-    -   "bsd" to use the UUID functions found in FreeBSD, NetBSD, and
-        some other BSD-derived systems
-
-    -   "e2fs" to use the UUID library created by the e2fsprogs project;
-        this library is present in most Linux systems and in macOS, and
-        can be obtained for other platforms as well
-
-    -   "ossp" to use the OSSP UUID library
-
---with-ossp-uuid
-
-    Obsolete equivalent of --with-uuid=ossp.
-
---with-libxml
-
-    Build with libxml2, enabling SQL/XML support. Libxml2 version 2.6.23
-    or later is required for this feature.
-
-    To detect the required compiler and linker options, PostgreSQL will
-    query "pkg-config", if that is installed and knows about libxml2.
-    Otherwise the program "xml2-config", which is installed by libxml2,
-    will be used if it is found. Use of "pkg-config" is preferred,
-    because it can deal with multi-architecture installations better.
-
-    To use a libxml2 installation that is in an unusual location, you
-    can set "pkg-config"-related environment variables (see its
-    documentation), or set the environment variable XML2_CONFIG to point
-    to the "xml2-config" program belonging to the libxml2 installation,
-    or set the variables XML2_CFLAGS and XML2_LIBS. (If "pkg-config" is
-    installed, then to override its idea of where libxml2 is you must
-    either set XML2_CONFIG or set both XML2_CFLAGS and XML2_LIBS to
-    nonempty strings.)
-
---with-libxslt
-
-    Build with libxslt, enabling the xml2 module to perform XSL
-    transformations of XML. "--with-libxml" must be specified as well.
-
-------------------------------------------------------------------------
-
-Anti-Features
-
-The options described in this section allow disabling certain PostgreSQL
-features that are built by default, but which might need to be turned
-off if the required software or system features are not available. Using
-these options is not recommended unless really necessary.
-
---without-readline
-
-    Prevents use of the Readline library (and libedit as well). This
-    option disables command-line editing and history in psql.
-
---with-libedit-preferred
-
-    Favors the use of the BSD-licensed libedit library rather than
-    GPL-licensed Readline. This option is significant only if you have
-    both libraries installed; the default in that case is to use
-    Readline.
-
---without-zlib
-
-    Prevents use of the Zlib library. This disables support for
-    compressed archives in pg_dump and pg_restore.
-
---disable-spinlocks
-
-    Allow the build to succeed even if PostgreSQL has no CPU spinlock
-    support for the platform. The lack of spinlock support will result
-    in very poor performance; therefore, this option should only be used
-    if the build aborts and informs you that the platform lacks spinlock
-    support. If this option is required to build PostgreSQL on your
-    platform, please report the problem to the PostgreSQL developers.
-
---disable-atomics
-
-    Disable use of CPU atomic operations. This option does nothing on
-    platforms that lack such operations. On platforms that do have them,
-    this will result in poor performance. This option is only useful for
-    debugging or making performance comparisons.
-
---disable-thread-safety
-
-    Disable the thread-safety of client libraries. This prevents
-    concurrent threads in libpq and ECPG programs from safely
-    controlling their private connection handles. Use this only on
-    platforms with deficient threading support.
-
-------------------------------------------------------------------------
-
-Build Process Details
-
---with-includes=DIRECTORIES
-
-    "DIRECTORIES" is a colon-separated list of directories that will be
-    added to the list the compiler searches for header files. If you
-    have optional packages (such as GNU Readline) installed in a
-    non-standard location, you have to use this option and probably also
-    the corresponding "--with-libraries" option.
-
-    Example: --with-includes=/opt/gnu/include:/usr/sup/include.
-
---with-libraries=DIRECTORIES
-
-    "DIRECTORIES" is a colon-separated list of directories to search for
-    libraries. You will probably have to use this option (and the
-    corresponding "--with-includes" option) if you have packages
-    installed in non-standard locations.
-
-    Example: --with-libraries=/opt/gnu/lib:/usr/sup/lib.
-
---with-system-tzdata=DIRECTORY 
-
-    PostgreSQL includes its own time zone database, which it requires
-    for date and time operations. This time zone database is in fact
-    compatible with the IANA time zone database provided by many
-    operating systems such as FreeBSD, Linux, and Solaris, so it would
-    be redundant to install it again. When this option is used, the
-    system-supplied time zone database in "DIRECTORY" is used instead of
-    the one included in the PostgreSQL source distribution. "DIRECTORY"
-    must be specified as an absolute path. "/usr/share/zoneinfo" is a
-    likely directory on some operating systems. Note that the
-    installation routine will not detect mismatching or erroneous time
-    zone data. If you use this option, you are advised to run the
-    regression tests to verify that the time zone data you have pointed
-    to works correctly with PostgreSQL.
-
-    This option is mainly aimed at binary package distributors who know
-    their target operating system well. The main advantage of using this
-    option is that the PostgreSQL package won't need to be upgraded
-    whenever any of the many local daylight-saving time rules change.
-    Another advantage is that PostgreSQL can be cross-compiled more
-    straightforwardly if the time zone database files do not need to be
-    built during the installation.
-
---with-extra-version=STRING
-
-    Append "STRING" to the PostgreSQL version number. You can use this,
-    for example, to mark binaries built from unreleased Git snapshots or
-    containing custom patches with an extra version string, such as a
-    "git describe" identifier or a distribution package release number.
-
---disable-rpath
-
-    Do not mark PostgreSQL's executables to indicate that they should
-    search for shared libraries in the installation's library directory
-    (see "--libdir"). On most platforms, this marking uses an absolute
-    path to the library directory, so that it will be unhelpful if you
-    relocate the installation later. However, you will then need to
-    provide some other way for the executables to find the shared
-    libraries. Typically this requires configuring the operating
-    system's dynamic linker to search the library directory; see the
-    section called "Shared Libraries" for more detail.
-
-------------------------------------------------------------------------
-
-Miscellaneous
-
-It's fairly common, particularly for test builds, to adjust the default
-port number with "--with-pgport". The other options in this section are
-recommended only for advanced users.
-
---with-pgport=NUMBER
-
-    Set "NUMBER" as the default port number for server and clients. The
-    default is 5432. The port can always be changed later on, but if you
-    specify it here then both server and clients will have the same
-    default compiled in, which can be very convenient. Usually the only
-    good reason to select a non-default value is if you intend to run
-    multiple PostgreSQL servers on the same machine.
-
---with-krb-srvnam=NAME
-
-    The default name of the Kerberos service principal used by GSSAPI.
-    postgres is the default. There's usually no reason to change this
-    unless you are building for a Windows environment, in which case it
-    must be set to upper case POSTGRES.
-
---with-segsize=SEGSIZE
-
-    Set the segment size, in gigabytes. Large tables are divided into
-    multiple operating-system files, each of size equal to the segment
-    size. This avoids problems with file size limits that exist on many
-    platforms. The default segment size, 1 gigabyte, is safe on all
-    supported platforms. If your operating system has "largefile"
-    support (which most do, nowadays), you can use a larger segment
-    size. This can be helpful to reduce the number of file descriptors
-    consumed when working with very large tables. But be careful not to
-    select a value larger than is supported by your platform and the
-    file systems you intend to use. Other tools you might wish to use,
-    such as tar, could also set limits on the usable file size. It is
-    recommended, though not absolutely required, that this value be a
-    power of 2. Note that changing this value breaks on-disk database
-    compatibility, meaning you cannot use "pg_upgrade" to upgrade to a
-    build with a different segment size.
-
---with-blocksize=BLOCKSIZE
-
-    Set the block size, in kilobytes. This is the unit of storage and
-    I/O within tables. The default, 8 kilobytes, is suitable for most
-    situations; but other values may be useful in special cases. The
-    value must be a power of 2 between 1 and 32 (kilobytes). Note that
-    changing this value breaks on-disk database compatibility, meaning
-    you cannot use "pg_upgrade" to upgrade to a build with a different
-    block size.
-
---with-wal-blocksize=BLOCKSIZE
-
-    Set the WAL block size, in kilobytes. This is the unit of storage
-    and I/O within the WAL log. The default, 8 kilobytes, is suitable
-    for most situations; but other values may be useful in special
-    cases. The value must be a power of 2 between 1 and 64 (kilobytes).
-    Note that changing this value breaks on-disk database compatibility,
-    meaning you cannot use "pg_upgrade" to upgrade to a build with a
-    different WAL block size.
-
-------------------------------------------------------------------------
-
-Developer Options
-
-Most of the options in this section are only of interest for developing
-or debugging PostgreSQL. They are not recommended for production builds,
-except for "--enable-debug", which can be useful to enable detailed bug
-reports in the unlucky event that you encounter a bug. On platforms
-supporting DTrace, "--enable-dtrace" may also be reasonable to use in
-production.
-
-When building an installation that will be used to develop code inside
-the server, it is recommended to use at least the options
-"--enable-debug" and "--enable-cassert".
-
---enable-debug
-
-    Compiles all programs and libraries with debugging symbols. This
-    means that you can run the programs in a debugger to analyze
-    problems. This enlarges the size of the installed executables
-    considerably, and on non-GCC compilers it usually also disables
-    compiler optimization, causing slowdowns. However, having the
-    symbols available is extremely helpful for dealing with any problems
-    that might arise. Currently, this option is recommended for
-    production installations only if you use GCC. But you should always
-    have it on if you are doing development work or running a beta
-    version.
-
---enable-cassert
-
-    Enables assertion checks in the server, which test for many "cannot
-    happen" conditions. This is invaluable for code development
-    purposes, but the tests can slow down the server significantly.
-    Also, having the tests turned on won't necessarily enhance the
-    stability of your server! The assertion checks are not categorized
-    for severity, and so what might be a relatively harmless bug will
-    still lead to server restarts if it triggers an assertion failure.
-    This option is not recommended for production use, but you should
-    have it on for development work or when running a beta version.
-
---enable-tap-tests
-
-    Enable tests using the Perl TAP tools. This requires a Perl
-    installation and the Perl module IPC::Run.
-
---enable-depend
-
-    Enables automatic dependency tracking. With this option, the
-    makefiles are set up so that all affected object files will be
-    rebuilt when any header file is changed. This is useful if you are
-    doing development work, but is just wasted overhead if you intend
-    only to compile once and install. At present, this option only works
-    with GCC.
-
---enable-coverage
-
-    If using GCC, all programs and libraries are compiled with code
-    coverage testing instrumentation. When run, they generate files in
-    the build directory with code coverage metrics. This option is for
-    use only with GCC and when doing development work.
-
---enable-profiling
-
-    If using GCC, all programs and libraries are compiled so they can be
-    profiled. On backend exit, a subdirectory will be created that
-    contains the "gmon.out" file containing profile data. This option is
-    for use only with GCC and when doing development work.
-
---enable-dtrace
-
-    Compiles PostgreSQL with support for the dynamic tracing tool
-    DTrace.
-
-    To point to the "dtrace" program, the environment variable DTRACE
-    can be set. This will often be necessary because "dtrace" is
-    typically installed under "/usr/sbin", which might not be in your
-    PATH.
-
-    Extra command-line options for the "dtrace" program can be specified
-    in the environment variable DTRACEFLAGS. On Solaris, to include
-    DTrace support in a 64-bit binary, you must specify
-    DTRACEFLAGS="-64". For example, using the GCC compiler:
-
-        ./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
-
-    Using Sun's compiler:
-
-        ./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
-
-------------------------------------------------------------------------
-
-configure Environment Variables
-
-In addition to the ordinary command-line options described above,
-"configure" responds to a number of environment variables. You can
-specify environment variables on the "configure" command line, for
-example:
-
-    ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
-
-In this usage an environment variable is little different from a
-command-line option. You can also set such variables beforehand:
-
-    export CC=/opt/bin/gcc
-    export CFLAGS='-O2 -pipe'
-    ./configure
-
-This usage can be convenient because many programs' configuration
-scripts respond to these variables in similar ways.
-
-The most commonly used of these environment variables are CC and CFLAGS.
-If you prefer a C compiler different from the one "configure" picks, you
-can set the variable CC to the program of your choice. By default,
-"configure" will pick "gcc" if available, else the platform's default
-(usually "cc"). Similarly, you can override the default compiler flags
-if needed with the CFLAGS variable.
-
-Here is a list of the significant variables that can be set in this
-manner:
-
-BISON
-
-    Bison program
-
-CC
-
-    C compiler
-
-CFLAGS
-
-    options to pass to the C compiler
-
-CLANG
-
-    path to "clang" program used to process source code for inlining
-    when compiling with --with-llvm
-
-CPP
-
-    C preprocessor
-
-CPPFLAGS
-
-    options to pass to the C preprocessor
-
-CXX
-
-    C++ compiler
-
-CXXFLAGS
-
-    options to pass to the C++ compiler
-
-DTRACE
-
-    location of the "dtrace" program
-
-DTRACEFLAGS
-
-    options to pass to the "dtrace" program
-
-FLEX
-
-    Flex program
-
-LDFLAGS
-
-    options to use when linking either executables or shared libraries
-
-LDFLAGS_EX
-
-    additional options for linking executables only
-
-LDFLAGS_SL
-
-    additional options for linking shared libraries only
-
-LLVM_CONFIG
-
-    "llvm-config" program used to locate the LLVM installation
-
-MSGFMT
-
-    "msgfmt" program for native language support
-
-PERL
-
-    Perl interpreter program. This will be used to determine the
-    dependencies for building PL/Perl. The default is "perl".
-
-PYTHON
-
-    Python interpreter program. This will be used to determine the
-    dependencies for building PL/Python. Also, whether Python 2 or 3 is
-    specified here (or otherwise implicitly chosen) determines which
-    variant of the PL/Python language becomes available. See the
-    PL/Python documentation for more information. If this is not set,
-    the following are probed in this order: python python3 python2.
-
-TCLSH
-
-    Tcl interpreter program. This will be used to determine the
-    dependencies for building PL/Tcl. If this is not set, the following
-    are probed in this order:
-    tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85          tclsh8.4 tclsh84.
-
-XML2_CONFIG
-
-    "xml2-config" program used to locate the libxml2 installation
-
-Sometimes it is useful to add compiler flags after-the-fact to the set
-that were chosen by "configure". An important example is that gcc's
-"-Werror" option cannot be included in the CFLAGS passed to "configure",
-because it will break many of "configure"'s built-in tests. To add such
-flags, include them in the COPT environment variable while running
-"make". The contents of COPT are added to both the CFLAGS and LDFLAGS
-options set up by "configure". For example, you could do
-
-    make COPT='-Werror'
-
-or
-
-    export COPT='-Werror'
-    make
-
-Note:
-
-If using GCC, it is best to build with an optimization level of at least
-"-O1", because using no optimization ("-O0") disables some important
-compiler warnings (such as the use of uninitialized variables). However,
-non-zero optimization levels can complicate debugging because stepping
-through compiled code will usually not match up one-to-one with source
-code lines. If you get confused while trying to debug optimized code,
-recompile the specific files of interest with "-O0". An easy way to do
-this is by passing an option to make: "make PROFILE=-O0 file.o".
-
-The COPT and PROFILE environment variables are actually handled
-identically by the PostgreSQL makefiles. Which to use is a matter of
-preference, but a common habit among developers is to use PROFILE for
-one-time flag adjustments, while COPT might be kept set all the time.
-
-------------------------------------------------------------------------
-
-Post-Installation Setup
-
-------------------------------------------------------------------------
-
-Shared Libraries
-
-On some systems with shared libraries you need to tell the system how to
-find the newly installed shared libraries. The systems on which this is
-*not* necessary include FreeBSD, HP-UX, Linux, NetBSD, OpenBSD, and
-Solaris.
-
-The method to set the shared library search path varies between
-platforms, but the most widely-used method is to set the environment
-variable LD_LIBRARY_PATH like so: In Bourne shells ("sh", "ksh", "bash",
-"zsh"):
-
-    LD_LIBRARY_PATH=/usr/local/pgsql/lib
-    export LD_LIBRARY_PATH
-
-or in "csh" or "tcsh":
-
-    setenv LD_LIBRARY_PATH /usr/local/pgsql/lib
-
-Replace /usr/local/pgsql/lib with whatever you set "--libdir" to in Step
-1. You should put these commands into a shell start-up file such as
-"/etc/profile" or "~/.bash_profile". Some good information about the
-caveats associated with this method can be found at
-http://xahlee.info/UnixResource_dir/_/ldpath.html.
-
-On some systems it might be preferable to set the environment variable
-LD_RUN_PATH *before* building.
-
-On Cygwin, put the library directory in the PATH or move the ".dll"
-files into the "bin" directory.
-
-If in doubt, refer to the manual pages of your system (perhaps "ld.so"
-or "rld"). If you later get a message like:
-
-    psql: error in loading shared libraries
-    libpq.so.2.1: cannot open shared object file: No such file or directory
-
-then this step was necessary. Simply take care of it then.
-
-If you are on Linux and you have root access, you can run:
-
-    /sbin/ldconfig /usr/local/pgsql/lib
-
-(or equivalent directory) after installation to enable the run-time
-linker to find the shared libraries faster. Refer to the manual page of
-"ldconfig" for more information. On FreeBSD, NetBSD, and OpenBSD the
-command is:
-
-    /sbin/ldconfig -m /usr/local/pgsql/lib
-
-instead. Other systems are not known to have an equivalent command.
-
-------------------------------------------------------------------------
-
-Environment Variables
-
-If you installed into "/usr/local/pgsql" or some other location that is
-not searched for programs by default, you should add
-"/usr/local/pgsql/bin" (or whatever you set "--bindir" to in Step 1)
-into your PATH. Strictly speaking, this is not necessary, but it will
-make the use of PostgreSQL much more convenient.
-
-To do this, add the following to your shell start-up file, such as
-"~/.bash_profile" (or "/etc/profile", if you want it to affect all
-users):
-
-    PATH=/usr/local/pgsql/bin:$PATH
-    export PATH
-
-If you are using "csh" or "tcsh", then use this command:
-
-    set path = ( /usr/local/pgsql/bin $path )
-
-To enable your system to find the man documentation, you need to add
-lines like the following to a shell start-up file unless you installed
-into a location that is searched by default:
-
-    MANPATH=/usr/local/pgsql/share/man:$MANPATH
-    export MANPATH
-
-The environment variables PGHOST and PGPORT specify to client
-applications the host and port of the database server, overriding the
-compiled-in defaults. If you are going to run client applications
-remotely then it is convenient if every user that plans to use the
-database sets PGHOST. This is not required, however; the settings can be
-communicated via command line options to most client programs.
-
-------------------------------------------------------------------------
-
-Getting Started
-
-The following is a quick summary of how to get PostgreSQL up and running
-once installed. The main documentation contains more information.
-
-1.  Create a user account for the PostgreSQL server. This is the user
-    the server will run as. For production use you should create a
-    separate, unprivileged account ("postgres" is commonly used). If you
-    do not have root access or just want to play around, your own user
-    account is enough, but running the server as root is a security risk
-    and will not work.
-
-        adduser postgres
-
-2.  Create a database installation with the "initdb" command. To run
-    "initdb" you must be logged in to your PostgreSQL server account. It
-    will not work as root.
-
-        root# mkdir /usr/local/pgsql/data
-        root# chown postgres /usr/local/pgsql/data
-        root# su - postgres
-        postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
-
-    The "-D" option specifies the location where the data will be
-    stored. You can use any path you want, it does not have to be under
-    the installation directory. Just make sure that the server account
-    can write to the directory (or create it, if it doesn't already
-    exist) before starting "initdb", as illustrated here.
-
-3.  At this point, if you did not use the "initdb" -A option, you might
-    want to modify "pg_hba.conf" to control local access to the server
-    before you start it. The default is to trust all local users.
-
-4.  The previous "initdb" step should have told you how to start up the
-    database server. Do so now. The command should look something like:
-
-        /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start
-
-    To stop a server running in the background you can type:
-
-        /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data stop
-
-5.  Create a database:
-
-        /usr/local/pgsql/bin/createdb testdb
-
-    Then enter:
-
-        /usr/local/pgsql/bin/psql testdb
-
-    to connect to that database. At the prompt you can enter SQL
-    commands and start experimenting.
-
-------------------------------------------------------------------------
-
-What Now?
-
--   The PostgreSQL distribution contains a comprehensive documentation
-    set, which you should read sometime. After installation, the
-    documentation can be accessed by pointing your browser to
-    "/usr/local/pgsql/doc/html/index.html", unless you changed the
-    installation directories.
-
-    The first few chapters of the main documentation are the Tutorial,
-    which should be your first reading if you are completely new to SQL
-    databases. If you are familiar with database concepts then you want
-    to proceed with part on server administration, which contains
-    information about how to set up the database server, database users,
-    and authentication.
-
--   Usually, you will want to modify your computer so that it will
-    automatically start the database server whenever it boots. Some
-    suggestions for this are in the documentation.
-
--   Run the regression tests against the installed server (using "make
-    installcheck"). If you didn't run the tests before installation, you
-    should definitely do it now. This is also explained in the
-    documentation.
-
--   By default, PostgreSQL is configured to run on minimal hardware.
-    This allows it to start up with almost any hardware configuration.
-    The default configuration is, however, not designed for optimum
-    performance. To achieve optimum performance, several server
-    parameters must be adjusted, the two most common being
-    shared_buffers and work_mem. Other parameters mentioned in the
-    documentation also affect performance.
-
-------------------------------------------------------------------------
-
-Supported Platforms
-
-A platform (that is, a CPU architecture and operating system
-combination) is considered supported by the PostgreSQL development
-community if the code contains provisions to work on that platform and
-it has recently been verified to build and pass its regression tests on
-that platform. Currently, most testing of platform compatibility is done
-automatically by test machines in the PostgreSQL Build Farm. If you are
-interested in using PostgreSQL on a platform that is not represented in
-the build farm, but on which the code works or can be made to work, you
-are strongly encouraged to set up a build farm member machine so that
-continued compatibility can be assured.
-
-In general, PostgreSQL can be expected to work on these CPU
-architectures: x86, x86_64, IA64, PowerPC, PowerPC 64, S/390, S/390x,
-Sparc, Sparc 64, ARM, MIPS, MIPSEL, and PA-RISC. Code support exists for
-M68K, M32R, and VAX, but these architectures are not known to have been
-tested recently. It is often possible to build on an unsupported CPU
-type by configuring with "--disable-spinlocks", but performance will be
-poor.
-
-PostgreSQL can be expected to work on these operating systems: Linux
-(all recent distributions), Windows (XP and later), FreeBSD, OpenBSD,
-NetBSD, macOS, AIX, HP/UX, and Solaris. Other Unix-like systems may also
-work but are not currently being tested. In most cases, all CPU
-architectures supported by a given operating system will work. Look in
-the section called "Platform-Specific Notes" below to see if there is
-information specific to your operating system, particularly if using an
-older system.
-
-If you have installation problems on a platform that is known to be
-supported according to recent build farm results, please report it to
-<[email protected]>. If you are interested in porting
-PostgreSQL to a new platform, <[email protected]> is
-the appropriate place to discuss that.
-
-------------------------------------------------------------------------
-
-Platform-Specific Notes
-
-This section documents additional platform-specific issues regarding the
-installation and setup of PostgreSQL. Be sure to read the installation
-instructions, and in particular the section called "Requirements" as
-well. Also, check the file "src/test/regress/README" and the
-documentation regarding the interpretation of regression test results.
-
-Platforms that are not covered here have no known platform-specific
-installation issues.
-
-------------------------------------------------------------------------
-
-AIX
-
-PostgreSQL works on AIX, but AIX versions before about 6.1 have various
-issues and are not recommended. You can use GCC or the native IBM
-compiler "xlc".
-
-------------------------------------------------------------------------
-
-Memory Management
-
-AIX can be somewhat peculiar with regards to the way it does memory
-management. You can have a server with many multiples of gigabytes of
-RAM free, but still get out of memory or address space errors when
-running applications. One example is loading of extensions failing with
-unusual errors. For example, running as the owner of the PostgreSQL
-installation:
-
-    =# CREATE EXTENSION plperl;
-    ERROR:  could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
-
-Running as a non-owner in the group possessing the PostgreSQL
-installation:
-
-    =# CREATE EXTENSION plperl;
-    ERROR:  could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
-
-Another example is out of memory errors in the PostgreSQL server logs,
-with every memory allocation near or greater than 256 MB failing.
-
-The overall cause of all these problems is the default bittedness and
-memory model used by the server process. By default, all binaries built
-on AIX are 32-bit. This does not depend upon hardware type or kernel in
-use. These 32-bit processes are limited to 4 GB of memory laid out in
-256 MB segments using one of a few models. The default allows for less
-than 256 MB in the heap as it shares a single segment with the stack.
-
-In the case of the plperl example, above, check your umask and the
-permissions of the binaries in your PostgreSQL installation. The
-binaries involved in that example were 32-bit and installed as mode 750
-instead of 755. Due to the permissions being set in this fashion, only
-the owner or a member of the possessing group can load the library.
-Since it isn't world-readable, the loader places the object into the
-process' heap instead of the shared library segments where it would
-otherwise be placed.
-
-The "ideal" solution for this is to use a 64-bit build of PostgreSQL,
-but that is not always practical, because systems with 32-bit processors
-can build, but not run, 64-bit binaries.
-
-If a 32-bit binary is desired, set LDR_CNTRL to MAXDATA=0xn0000000,
-where 1 <= n <= 8, before starting the PostgreSQL server, and try
-different values and "postgresql.conf" settings to find a configuration
-that works satisfactorily. This use of LDR_CNTRL tells AIX that you want
-the server to have MAXDATA bytes set aside for the heap, allocated in
-256 MB segments. When you find a workable configuration, "ldedit" can be
-used to modify the binaries so that they default to using the desired
-heap size. PostgreSQL can also be rebuilt, passing
-configure      LDFLAGS="-Wl,-bmaxdata:0xn0000000" to achieve the same
-effect.
-
-For a 64-bit build, set OBJECT_MODE to 64 and pass CC="gcc -maix64" and
-LDFLAGS="-Wl,-bbigtoc" to "configure". (Options for "xlc" might differ.)
-If you omit the export of OBJECT_MODE, your build may fail with linker
-errors. When OBJECT_MODE is set, it tells AIX's build utilities such as
-"ar", "as", and "ld" what type of objects to default to handling.
-
-By default, overcommit of paging space can happen. While we have not
-seen this occur, AIX will kill processes when it runs out of memory and
-the overcommit is accessed. The closest to this that we have seen is
-fork failing because the system decided that there was not enough memory
-for another process. Like many other parts of AIX, the paging space
-allocation method and out-of-memory kill is configurable on a system- or
-process-wide basis if this becomes a problem.
-
-------------------------------------------------------------------------
-
-Cygwin
-
-PostgreSQL can be built using Cygwin, a Linux-like environment for
-Windows, but that method is inferior to the native Windows build and
-running a server under Cygwin is no longer recommended.
-
-When building from source, proceed according to the Unix-style
-installation procedure (i.e., ./configure;     make; etc.), noting the
-following Cygwin-specific differences:
-
--   Set your path to use the Cygwin bin directory before the Windows
-    utilities. This will help prevent problems with compilation.
-
--   The "adduser" command is not supported; use the appropriate user
-    management application on Windows NT, 2000, or XP. Otherwise, skip
-    this step.
-
--   The "su" command is not supported; use ssh to simulate su on Windows
-    NT, 2000, or XP. Otherwise, skip this step.
-
--   OpenSSL is not supported.
-
--   Start "cygserver" for shared memory support. To do this, enter the
-    command /usr/sbin/cygserver        &. This program needs to be
-    running anytime you start the PostgreSQL server or initialize a
-    database cluster ("initdb"). The default "cygserver" configuration
-    may need to be changed (e.g., increase SEMMNS) to prevent PostgreSQL
-    from failing due to a lack of system resources.
-
--   Building might fail on some systems where a locale other than C is
-    in use. To fix this, set the locale to C by doing "export
-    LANG=C.utf8" before building, and then setting it back to the
-    previous setting after you have installed PostgreSQL.
-
--   The parallel regression tests (make check) can generate spurious
-    regression test failures due to overflowing the listen() backlog
-    queue which causes connection refused errors or hangs. You can limit
-    the number of connections using the make variable MAX_CONNECTIONS
-    thus:
-
-        make MAX_CONNECTIONS=5 check
-
-    (On some systems you can have up to about 10 simultaneous
-    connections.)
-
-It is possible to install "cygserver" and the PostgreSQL server as
-Windows NT services. For information on how to do this, please refer to
-the "README" document included with the PostgreSQL binary package on
-Cygwin. It is installed in the directory "/usr/share/doc/Cygwin".
-
-------------------------------------------------------------------------
-
-macOS
-
-To build PostgreSQL from source on macOS, you will need to install
-Apple's command line developer tools, which can be done by issuing
-
-    xcode-select --install
-
-(note that this will pop up a GUI dialog window for confirmation). You
-may or may not wish to also install Xcode.
-
-On recent macOS releases, it's necessary to embed the "sysroot" path in
-the include switches used to find some system header files. This results
-in the outputs of the configure script varying depending on which SDK
-version was used during configure. That shouldn't pose any problem in
-simple scenarios, but if you are trying to do something like building an
-extension on a different machine than the server code was built on, you
-may need to force use of a different sysroot path. To do that, set
-PG_SYSROOT, for example
-
-    make PG_SYSROOT=/desired/path all
-
-To find out the appropriate path on your machine, run
-
-    xcrun --show-sdk-path
-
-Note that building an extension using a different sysroot version than
-was used to build the core server is not really recommended; in the
-worst case it could result in hard-to-debug ABI inconsistencies.
-
-You can also select a non-default sysroot path when configuring, by
-specifying PG_SYSROOT to configure:
-
-    ./configure ... PG_SYSROOT=/desired/path
-
-This would primarily be useful to cross-compile for some other macOS
-version. There is no guarantee that the resulting executables will run
-on the current host.
-
-To suppress the "-isysroot" options altogether, use
-
-    ./configure ... PG_SYSROOT=none
-
-(any nonexistent pathname will work). This might be useful if you wish
-to build with a non-Apple compiler, but beware that that case is not
-tested or supported by the PostgreSQL developers.
-
-macOS's "System Integrity Protection" (SIP) feature breaks make check,
-because it prevents passing the needed setting of DYLD_LIBRARY_PATH down
-to the executables being tested. You can work around that by doing
-make     install before make check. Most PostgreSQL developers just turn
-off SIP, though.
-
-------------------------------------------------------------------------
-
-MinGW/Native Windows
-
-PostgreSQL for Windows can be built using MinGW, a Unix-like build
-environment for Microsoft operating systems, or using Microsoft's Visual
-C++ compiler suite. The MinGW build procedure uses the normal build
-system described in this chapter; the Visual C++ build works completely
-differently and is described in the documentation.
-
-The native Windows port requires a 32 or 64-bit version of Windows 2000
-or later. Earlier operating systems do not have sufficient
-infrastructure (but Cygwin may be used on those). MinGW, the Unix-like
-build tools, and MSYS, a collection of Unix tools required to run shell
-scripts like "configure", can be downloaded from http://www.mingw.org/.
-Neither is required to run the resulting binaries; they are needed only
-for creating the binaries.
-
-To build 64 bit binaries using MinGW, install the 64 bit tool set from
-https://mingw-w64.org/, put its bin directory in the PATH, and run
-"configure" with the "--host=x86_64-w64-mingw32" option.
-
-After you have everything installed, it is suggested that you run psql
-under "CMD.EXE", as the MSYS console has buffering issues.
-
-------------------------------------------------------------------------
-
-Collecting Crash Dumps on Windows
-
-If PostgreSQL on Windows crashes, it has the ability to generate
-minidumps that can be used to track down the cause for the crash,
-similar to core dumps on Unix. These dumps can be read using the Windows
-Debugger Tools or using Visual Studio. To enable the generation of dumps
-on Windows, create a subdirectory named "crashdumps" inside the cluster
-data directory. The dumps will then be written into this directory with
-a unique name based on the identifier of the crashing process and the
-current time of the crash.
-
-------------------------------------------------------------------------
-
-Solaris
-
-PostgreSQL is well-supported on Solaris. The more up to date your
-operating system, the fewer issues you will experience.
-
-------------------------------------------------------------------------
-
-Required Tools
-
-You can build with either GCC or Sun's compiler suite. For better code
-optimization, Sun's compiler is strongly recommended on the SPARC
-architecture. If you are using Sun's compiler, be careful not to select
-"/usr/ucb/cc"; use "/opt/SUNWspro/bin/cc".
-
-You can download Sun Studio from
-https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/.
-Many GNU tools are integrated into Solaris 10, or they are present on
-the Solaris companion CD. If you need packages for older versions of
-Solaris, you can find these tools at http://www.sunfreeware.com. If you
-prefer sources, look at https://www.gnu.org/prep/ftp.
-
-------------------------------------------------------------------------
-
-configure Complains About a Failed Test Program
-
-If "configure" complains about a failed test program, this is probably a
-case of the run-time linker being unable to find some library, probably
-libz, libreadline or some other non-standard library such as libssl. To
-point it to the right location, set the LDFLAGS environment variable on
-the "configure" command line, e.g.,
-
-    configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
-
-See the ld man page for more information.
-
-------------------------------------------------------------------------
-
-Compiling for Optimal Performance
-
-On the SPARC architecture, Sun Studio is strongly recommended for
-compilation. Try using the "-xO5" optimization flag to generate
-significantly faster binaries. Do not use any flags that modify behavior
-of floating-point operations and errno processing (e.g., "-fast").
-
-If you do not have a reason to use 64-bit binaries on SPARC, prefer the
-32-bit version. The 64-bit operations are slower and 64-bit binaries are
-slower than the 32-bit variants. On the other hand, 32-bit code on the
-AMD64 CPU family is not native, so 32-bit code is significantly slower
-on that CPU family.
-
-------------------------------------------------------------------------
-
-Using DTrace for Tracing PostgreSQL
-
-Yes, using DTrace is possible. See the documentation for further
-information.
-
-If you see the linking of the "postgres" executable abort with an error
-message like:
-
-    Undefined                       first referenced
-     symbol                             in file
-    AbortTransaction                    utils/probes.o
-    CommitTransaction                   utils/probes.o
-    ld: fatal: Symbol referencing errors. No output written to postgres
-    collect2: ld returned 1 exit status
-    make: *** [postgres] Error 1
-
-your DTrace installation is too old to handle probes in static
-functions. You need Solaris 10u4 or newer to use DTrace.