2003-09-28 00:24:45 +08:00
dnl Process this file with autoconf to produce a configure script.
2010-09-21 04:08:53 +08:00
dnl configure.in
2002-05-25 02:10:17 +08:00
dnl
2000-07-09 21:14:19 +08:00
dnl Developers, please strive to achieve this order:
dnl
dnl 0. Initialization and options processing
dnl 1. Programs
dnl 2. Libraries
2004-05-21 13:08:06 +08:00
dnl 3. Header files
2000-07-09 21:14:19 +08:00
dnl 4. Types
dnl 5. Structures
dnl 6. Compiler characteristics
dnl 7. Functions, global variables
dnl 8. System services
dnl
dnl Read the Autoconf manual for details.
2002-05-25 02:10:17 +08:00
dnl
m4_pattern_forbid(^PGAC_)dnl to catch undefined macros
2003-11-24 22:52:58 +08:00
2020-02-28 15:54:49 +08:00
AC_INIT([PostgreSQL], [13devel], [pgsql-bugs@lists.postgresql.org], [], [https://www.postgresql.org/])
2002-03-30 01:32:55 +08:00
2013-12-19 09:53:23 +08:00
m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.69], [], [m4_fatal([Autoconf version 2.69 is required.
2008-01-01 01:28:21 +08:00
Untested combinations of 'autoconf' and PostgreSQL versions are not
recommended. You can remove the check from 'configure.in' but it is then
your responsibility whether the result works or not.])])
2020-01-02 01:21:45 +08:00
AC_COPYRIGHT([Copyright (c) 1996-2020, PostgreSQL Global Development Group])
2002-03-30 01:32:55 +08:00
AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c])
2000-07-09 21:14:19 +08:00
AC_CONFIG_AUX_DIR(config)
2002-03-30 01:32:55 +08:00
AC_PREFIX_DEFAULT(/usr/local/pgsql)
2020-02-11 00:12:46 +08:00
AC_DEFINE_UNQUOTED(CONFIGURE_ARGS, ["$ac_configure_args"], [Saved arguments from configure])
2000-06-11 02:02:12 +08:00
2016-08-16 01:49:49 +08:00
[PG_MAJORVERSION=`expr "$PACKAGE_VERSION" : '\([0-9][0-9]*\)'`]
2008-12-11 15:34:09 +08:00
AC_SUBST(PG_MAJORVERSION)
AC_DEFINE_UNQUOTED(PG_MAJORVERSION, "$PG_MAJORVERSION", [PostgreSQL major version as a string])
2000-10-21 05:04:27 +08:00
2013-12-13 10:53:21 +08:00
PGAC_ARG_REQ(with, extra-version, [STRING], [append STRING to version],
[PG_VERSION="$PACKAGE_VERSION$withval"],
[PG_VERSION="$PACKAGE_VERSION"])
AC_DEFINE_UNQUOTED(PG_VERSION, "$PG_VERSION", [PostgreSQL version as a string])
1997-04-04 05:26:36 +08:00
AC_CANONICAL_HOST
1998-02-04 21:19:32 +08:00
2000-07-15 23:54:52 +08:00
template=
AC_MSG_CHECKING([which template to use])
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, template, [NAME], [override operating system template],
2000-09-22 04:17:43 +08:00
[
case $withval in
2000-07-15 23:54:52 +08:00
list) echo; ls "$srcdir/src/template"; exit;;
*) if test -f "$srcdir/src/template/$with_template" ; then
2000-09-22 04:17:43 +08:00
template=$withval
2000-07-15 23:54:52 +08:00
else
2000-11-27 02:15:42 +08:00
AC_MSG_ERROR(['$withval' is not a valid template name. Use 'list' for a list.])
2000-07-15 23:54:52 +08:00
fi;;
esac
2000-09-22 04:17:43 +08:00
],
[
2003-08-12 02:07:38 +08:00
# --with-template not given
2000-07-15 23:54:52 +08:00
case $host_os in
aix*) template=aix ;;
2019-12-19 15:28:37 +08:00
cygwin*|msys*) template=cygwin ;;
2000-11-01 03:55:20 +08:00
darwin*) template=darwin ;;
2011-03-03 03:15:28 +08:00
dragonfly*) template=netbsd ;;
2000-07-15 23:54:52 +08:00
freebsd*) template=freebsd ;;
hpux*) template=hpux ;;
2004-09-18 06:31:59 +08:00
linux*|gnu*|k*bsd*-gnu)
template=linux ;;
2003-05-16 00:35:30 +08:00
mingw*) template=win32 ;;
2000-07-15 23:54:52 +08:00
netbsd*) template=netbsd ;;
openbsd*) template=openbsd ;;
2000-10-11 05:22:29 +08:00
solaris*) template=solaris ;;
1997-02-04 16:53:45 +08:00
esac
1997-04-09 16:55:32 +08:00
2000-07-15 23:54:52 +08:00
if test x"$template" = x"" ; then
2000-11-27 02:15:42 +08:00
AC_MSG_ERROR([[
2000-07-15 23:54:52 +08:00
*******************************************************************
PostgreSQL has apparently not been ported to your platform yet.
2000-07-18 06:31:59 +08:00
To try a manual configuration, look into the src/template directory
2000-11-27 02:15:42 +08:00
for a similar platform and use the '--with-template=' option.
2000-07-15 23:54:52 +08:00
2020-02-28 15:54:49 +08:00
Please also contact <]AC_PACKAGE_BUGREPORT[> to see about
2000-11-27 02:15:42 +08:00
rectifying this. Include the above 'checking host system type...'
2000-07-15 23:54:52 +08:00
line.
*******************************************************************
2000-11-27 02:15:42 +08:00
]])
2000-07-15 23:54:52 +08:00
fi
1998-10-30 12:54:06 +08:00
2000-09-22 04:17:43 +08:00
])
1998-02-04 21:19:32 +08:00
2000-07-15 23:54:52 +08:00
AC_MSG_RESULT([$template])
1998-10-23 10:49:17 +08:00
2000-07-15 23:54:52 +08:00
PORTNAME=$template
AC_SUBST(PORTNAME)
1999-12-18 02:18:26 +08:00
2003-12-24 02:40:53 +08:00
# Initialize default assumption that we do not need separate assembly code
# for TAS (test-and-set). This can be overridden by the template file
# when it's executed.
need_tas=no
tas_file=dummy.s
1997-04-09 16:55:32 +08:00
1998-12-14 04:03:07 +08:00
1997-04-09 16:55:32 +08:00
2000-07-15 23:54:52 +08:00
##
## Command line options
##
2000-06-17 08:10:40 +08:00
2000-07-15 23:54:52 +08:00
#
# Add non-standard directories to the include path
#
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, includes, [DIRS], [look for additional header files in DIRS])
1997-04-09 16:55:32 +08:00
1998-04-10 10:59:38 +08:00
2000-07-15 23:54:52 +08:00
#
# Add non-standard directories to the library search path
#
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, libraries, [DIRS], [look for additional libraries in DIRS],
2000-09-22 04:17:43 +08:00
[LIBRARY_DIRS=$withval])
1997-04-09 16:55:32 +08:00
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, libs, [DIRS], [alternative spelling of --with-libraries],
2000-09-22 04:17:43 +08:00
[LIBRARY_DIRS=$withval])
2000-06-08 00:27:00 +08:00
1997-04-09 16:55:32 +08:00
2000-07-13 06:59:15 +08:00
#
2017-02-24 00:40:12 +08:00
# 64-bit integer date/time storage is now the only option, but to avoid
# unnecessary breakage of build scripts, continue to accept an explicit
# "--enable-integer-datetimes" switch.
2002-04-22 03:56:30 +08:00
#
2017-02-24 00:40:12 +08:00
PGAC_ARG_BOOL(enable, integer-datetimes, yes, [obsolete option, no longer supported],
[],
[AC_MSG_ERROR([--disable-integer-datetimes is no longer supported])])
2002-04-22 03:56:30 +08:00
2001-06-03 02:25:18 +08:00
#
# NLS
#
AC_MSG_CHECKING([whether NLS is wanted])
PGAC_ARG_OPTARG(enable, nls,
2008-10-29 17:27:24 +08:00
[LANGUAGES], [enable Native Language Support],
2001-06-03 02:25:18 +08:00
[],
[WANTED_LANGUAGES=$enableval],
2002-03-30 01:32:55 +08:00
[AC_DEFINE(ENABLE_NLS, 1,
2003-04-07 06:45:23 +08:00
[Define to 1 if you want National Language Support. (--enable-nls)])])
2001-06-03 02:25:18 +08:00
AC_MSG_RESULT([$enable_nls])
AC_SUBST(enable_nls)
AC_SUBST(WANTED_LANGUAGES)
2000-07-13 06:59:15 +08:00
#
# Default port number (--with-pgport), default 5432
#
AC_MSG_CHECKING([for default port number])
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, pgport, [PORTNUM], [set default port number [5432]],
2000-09-22 04:17:43 +08:00
[default_port=$withval],
[default_port=5432])
2001-02-08 04:13:27 +08:00
AC_MSG_RESULT([$default_port])
# Need both of these because some places want an integer and some a string
2002-03-30 01:32:55 +08:00
AC_DEFINE_UNQUOTED(DEF_PGPORT, ${default_port},
2003-04-07 06:45:23 +08:00
[Define to the default TCP port number on which the server listens and
2003-08-12 02:07:38 +08:00
to which clients will try to connect. This can be overridden at run-time,
but it's convenient if your clients have the right default compiled in.
(--with-pgport=PORTNUM)])
2002-03-30 01:32:55 +08:00
AC_DEFINE_UNQUOTED(DEF_PGPORT_STR, "${default_port}",
2003-08-12 02:07:38 +08:00
[Define to the default TCP port number as a string constant.])
2001-02-08 04:13:27 +08:00
AC_SUBST(default_port)
1997-04-09 16:55:32 +08:00
2016-03-14 22:41:29 +08:00
# It's worth validating port; you can get very confusing errors otherwise
if test x"$default_port" = x""; then
AC_MSG_ERROR([invalid --with-pgport specification: empty string])
elif test ! x`echo "$default_port" | sed -e 's/[[0-9]]*//'` = x""; then
AC_MSG_ERROR([invalid --with-pgport specification: must be a number])
elif test ! x`echo "$default_port" | sed -e 's/^0.//'` = x"$default_port"; then
AC_MSG_ERROR([invalid --with-pgport specification: must not have leading 0])
elif test "$default_port" -lt "1" -o "$default_port" -gt "65535"; then
AC_MSG_ERROR([invalid --with-pgport specification: must be between 1 and 65535])
fi
2000-10-28 07:59:39 +08:00
#
# '-rpath'-like feature can be disabled
#
PGAC_ARG_BOOL(enable, rpath, yes,
2008-10-29 17:27:24 +08:00
[do not embed shared library search path in executables])
2000-10-28 07:59:39 +08:00
AC_SUBST(enable_rpath)
2003-09-14 01:01:09 +08:00
#
# Spinlocks
#
PGAC_ARG_BOOL(enable, spinlocks, yes,
2008-10-29 17:27:24 +08:00
[do not use spinlocks])
2000-10-24 05:44:12 +08:00
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-26 05:49:05 +08:00
#
# Atomic operations
#
PGAC_ARG_BOOL(enable, atomics, yes,
[do not use atomic operations])
2000-11-04 22:29:26 +08:00
#
# --enable-debug adds -g to compiler flags
#
PGAC_ARG_BOOL(enable, debug, no,
2008-10-29 17:27:24 +08:00
[build with debugging symbols (-g)])
2002-03-06 01:55:23 +08:00
AC_SUBST(enable_debug)
2000-11-04 22:29:26 +08:00
2007-02-21 23:12:39 +08:00
#
# --enable-profiling enables gcc profiling
#
PGAC_ARG_BOOL(enable, profiling, no,
2008-10-29 17:27:24 +08:00
[build with profiling enabled ])
2007-02-21 23:12:39 +08:00
2008-09-05 20:11:18 +08:00
#
# --enable-coverage enables generation of code coverage metrics with gcov
#
PGAC_ARG_BOOL(enable, coverage, no,
2008-10-29 17:27:24 +08:00
[build with coverage testing instrumentation],
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
[PGAC_PATH_PROGS(GCOV, gcov)
2008-09-05 20:11:18 +08:00
if test -z "$GCOV"; then
AC_MSG_ERROR([gcov not found])
fi
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
PGAC_PATH_PROGS(LCOV, lcov)
2008-09-05 20:11:18 +08:00
if test -z "$LCOV"; then
AC_MSG_ERROR([lcov not found])
fi
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
PGAC_PATH_PROGS(GENHTML, genhtml)
2008-09-05 20:11:18 +08:00
if test -z "$GENHTML"; then
AC_MSG_ERROR([genhtml not found])
2008-09-06 02:54:58 +08:00
fi])
2008-09-05 20:11:18 +08:00
AC_SUBST(enable_coverage)
2006-07-25 00:32:45 +08:00
#
# DTrace
#
PGAC_ARG_BOOL(enable, dtrace, no,
2008-10-29 17:27:24 +08:00
[build with DTrace support],
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
[PGAC_PATH_PROGS(DTRACE, dtrace)
2006-08-18 01:25:43 +08:00
if test -z "$DTRACE"; then
AC_MSG_ERROR([dtrace not found])
fi
2006-07-25 00:32:45 +08:00
AC_SUBST(DTRACEFLAGS)])
AC_SUBST(enable_dtrace)
2014-11-02 22:14:36 +08:00
#
# TAP tests
#
PGAC_ARG_BOOL(enable, tap-tests, no,
[enable TAP tests (requires Perl and IPC::Run)])
AC_SUBST(enable_tap_tests)
2008-03-11 04:06:27 +08:00
#
2008-05-02 09:08:27 +08:00
# Block size
#
AC_MSG_CHECKING([for block size])
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, blocksize, [BLOCKSIZE], [set table block size in kB [8]],
2008-05-02 09:08:27 +08:00
[blocksize=$withval],
[blocksize=8])
case ${blocksize} in
1) BLCKSZ=1024;;
2) BLCKSZ=2048;;
4) BLCKSZ=4096;;
8) BLCKSZ=8192;;
16) BLCKSZ=16384;;
32) BLCKSZ=32768;;
*) AC_MSG_ERROR([Invalid block size. Allowed values are 1,2,4,8,16,32.])
esac
AC_MSG_RESULT([${blocksize}kB])
AC_DEFINE_UNQUOTED([BLCKSZ], ${BLCKSZ}, [
Size of a disk block --- this also limits the size of a tuple. You
can set it bigger if you need bigger tuples (although TOAST should
reduce the need to have large tuples, since fields can be spread
across multiple tuples).
2010-11-24 04:27:50 +08:00
2008-05-02 09:08:27 +08:00
BLCKSZ must be a power of 2. The maximum possible value of BLCKSZ
is currently 2^15 (32768). This is determined by the 15-bit widths
of the lp_off and lp_len fields in ItemIdData (see
include/storage/itemid.h).
2010-11-24 04:27:50 +08:00
2008-05-02 09:08:27 +08:00
Changing BLCKSZ requires an initdb.
2010-11-24 04:27:50 +08:00
])
2008-05-02 09:08:27 +08:00
#
2008-05-03 03:52:37 +08:00
# Relation segment size
2008-05-02 09:08:27 +08:00
#
AC_MSG_CHECKING([for segment size])
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, segsize, [SEGSIZE], [set table segment size in GB [1]],
2008-05-02 09:08:27 +08:00
[segsize=$withval],
[segsize=1])
# this expression is set up to avoid unnecessary integer overflow
2008-05-03 08:24:06 +08:00
# blocksize is already guaranteed to be a factor of 1024
RELSEG_SIZE=`expr '(' 1024 / ${blocksize} ')' '*' ${segsize} '*' 1024`
2008-05-02 09:08:27 +08:00
test $? -eq 0 || exit 1
AC_MSG_RESULT([${segsize}GB])
AC_DEFINE_UNQUOTED([RELSEG_SIZE], ${RELSEG_SIZE}, [
RELSEG_SIZE is the maximum number of blocks allowed in one disk file.
Thus, the maximum size of a single file is RELSEG_SIZE * BLCKSZ;
relations bigger than that are divided into multiple files.
2010-11-24 04:27:50 +08:00
2008-05-02 09:08:27 +08:00
RELSEG_SIZE * BLCKSZ must be less than your OS' limit on file size.
This is often 2 GB or 4GB in a 32-bit operating system, unless you
have large file support enabled. By default, we make the limit 1 GB
to avoid any possible integer-overflow problems within the OS.
A limit smaller than necessary only means we divide a large
relation into more chunks than necessary, so it seems best to err
in the direction of a small limit.
A power-of-2 value is recommended to save a few cycles in md.c,
but is not absolutely required.
Changing RELSEG_SIZE requires an initdb.
])
2008-03-11 04:06:27 +08:00
2008-05-03 03:52:37 +08:00
#
# WAL block size
#
AC_MSG_CHECKING([for WAL block size])
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, wal-blocksize, [BLOCKSIZE], [set WAL block size in kB [8]],
2008-05-03 03:52:37 +08:00
[wal_blocksize=$withval],
[wal_blocksize=8])
case ${wal_blocksize} in
1) XLOG_BLCKSZ=1024;;
2) XLOG_BLCKSZ=2048;;
4) XLOG_BLCKSZ=4096;;
8) XLOG_BLCKSZ=8192;;
16) XLOG_BLCKSZ=16384;;
32) XLOG_BLCKSZ=32768;;
64) XLOG_BLCKSZ=65536;;
*) AC_MSG_ERROR([Invalid WAL block size. Allowed values are 1,2,4,8,16,32,64.])
esac
AC_MSG_RESULT([${wal_blocksize}kB])
AC_DEFINE_UNQUOTED([XLOG_BLCKSZ], ${XLOG_BLCKSZ}, [
Size of a WAL file block. This need have no particular relation to BLCKSZ.
XLOG_BLCKSZ must be a power of 2, and if your system supports O_DIRECT I/O,
XLOG_BLCKSZ must be a multiple of the alignment requirement for direct-I/O
buffers, else direct I/O may fail.
Changing XLOG_BLCKSZ requires an initdb.
2010-11-24 04:27:50 +08:00
])
2008-05-03 03:52:37 +08:00
2000-07-13 06:59:15 +08:00
#
2000-07-15 23:54:52 +08:00
# C compiler
#
2000-07-13 06:59:15 +08:00
# For historical reasons you can also use --with-CC to specify the C compiler
# to use, although the standard way to do this is to set the CC environment
# variable.
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, CC, [CMD], [set compiler (deprecated)], [CC=$with_CC])
2000-06-10 11:16:34 +08:00
2002-03-30 01:32:55 +08:00
case $template in
2018-03-21 06:41:15 +08:00
aix) pgac_cc_list="gcc xlc"; pgac_cxx_list="g++ xlC";;
*) pgac_cc_list="gcc cc"; pgac_cxx_list="g++ c++";;
2002-03-30 01:32:55 +08:00
esac
2000-11-04 22:29:26 +08:00
2002-03-30 01:32:55 +08:00
AC_PROG_CC([$pgac_cc_list])
2018-08-16 16:32:05 +08:00
AC_PROG_CC_C99()
2018-08-24 09:33:40 +08:00
# Error out if the compiler does not support C99, as the codebase
# relies on that.
if test "$ac_cv_prog_cc_c99" = no; then
AC_MSG_ERROR([C compiler "$CC" does not support C99])
fi
2018-03-21 06:41:15 +08:00
AC_PROG_CXX([$pgac_cxx_list])
2003-08-12 02:07:38 +08:00
2007-08-05 23:43:00 +08:00
# Check if it's Intel's compiler, which (usually) pretends to be gcc,
# but has idiosyncrasies of its own. We assume icc will define
# __INTEL_COMPILER regardless of CFLAGS.
2015-07-03 00:21:23 +08:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@ifndef __INTEL_COMPILER
2007-08-05 23:43:00 +08:00
choke me
2015-07-03 00:21:23 +08:00
@%:@endif])], [ICC=yes], [ICC=no])
2007-08-05 23:43:00 +08:00
2008-10-30 00:06:47 +08:00
# Check if it's Sun Studio compiler. We assume that
# __SUNPRO_C will be defined for Sun Studio compilers
2015-07-03 00:21:23 +08:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@ifndef __SUNPRO_C
2008-10-30 00:06:47 +08:00
choke me
2015-07-03 00:21:23 +08:00
@%:@endif])], [SUN_STUDIO_CC=yes], [SUN_STUDIO_CC=no])
2008-10-30 00:06:47 +08:00
AC_SUBST(SUN_STUDIO_CC)
2018-03-21 08:26:25 +08:00
#
# LLVM
#
# Checked early because subsequent tests depend on it.
PGAC_ARG_BOOL(with, llvm, no, [build with LLVM based JIT support],
[AC_DEFINE([USE_LLVM], 1, [Define to 1 to build with LLVM based JIT support. (--with-llvm)])])
AC_SUBST(with_llvm)
2018-11-18 12:16:00 +08:00
dnl must use AS_IF here, else AC_REQUIRES inside PGAC_LLVM_SUPPORT malfunctions
2018-11-20 01:01:47 +08:00
AS_IF([test "$with_llvm" = yes], [
PGAC_LLVM_SUPPORT()
]) # fi
2018-03-21 08:26:25 +08:00
2003-11-02 04:48:51 +08:00
unset CFLAGS
2018-03-22 09:40:23 +08:00
unset CXXFLAGS
2003-10-25 23:32:11 +08:00
2003-08-12 02:07:38 +08:00
#
2000-07-15 23:54:52 +08:00
# Read the template
2003-08-12 02:07:38 +08:00
#
2000-07-15 23:54:52 +08:00
. "$srcdir/src/template/$template" || exit
2000-11-04 22:29:26 +08:00
2018-03-21 06:41:15 +08:00
# C[XX]FLAGS are selected so:
2003-10-25 23:32:11 +08:00
# If the user specifies something in the environment, that is used.
# else: If the template file set something, that is used.
2008-09-05 20:11:18 +08:00
# else: If coverage was enabled, don't set anything.
2003-10-25 23:32:11 +08:00
# else: If the compiler is GCC, then we use -O2.
2009-02-12 04:02:40 +08:00
# else: If the compiler is something else, then we use -O, unless debugging.
2003-10-25 23:32:11 +08:00
2002-03-30 01:32:55 +08:00
if test "$ac_env_CFLAGS_set" = set; then
CFLAGS=$ac_env_CFLAGS_value
2003-11-02 04:48:51 +08:00
elif test "${CFLAGS+set}" = set; then
2003-10-25 23:32:11 +08:00
: # (keep what template set)
2008-09-05 20:11:18 +08:00
elif test "$enable_coverage" = yes; then
: # no optimization by default
2003-10-25 23:32:11 +08:00
elif test "$GCC" = yes; then
CFLAGS="-O2"
2003-10-14 08:48:09 +08:00
else
2003-11-02 04:48:51 +08:00
# if the user selected debug mode, don't use -O
if test "$enable_debug" != yes; then
CFLAGS="-O"
fi
2000-11-04 22:29:26 +08:00
fi
2003-10-25 23:32:11 +08:00
2018-03-21 06:41:15 +08:00
if test "$ac_env_CXXFLAGS_set" = set; then
CXXFLAGS=$ac_env_CXXFLAGS_value
elif test "${CXXFLAGS+set}" = set; then
: # (keep what template set)
elif test "$enable_coverage" = yes; then
: # no optimization by default
elif test "$GCC" = yes; then
CXXFLAGS="-O2"
else
# if the user selected debug mode, don't use -O
if test "$enable_debug" != yes; then
CXXFLAGS="-O"
fi
fi
2018-03-21 08:26:25 +08:00
# When generating bitcode (for inlining) we always want to use -O2
# even when --enable-debug is specified. The bitcode it's not going to
# be used for line-by-line debugging, and JIT inlining doesn't work
# without at least -O1 (otherwise clang will emit 'noinline'
# attributes everywhere), which is bad for testing. Still allow the
# environment to override if done explicitly.
if test "$ac_env_BITCODE_CFLAGS_set" = set; then
BITCODE_CFLAGS=$ac_env_BITCODE_CFLAGS_value
else
BITCODE_CFLAGS="-O2 $BITCODE_CFLAGS"
fi
if test "$ac_env_BITCODE_CXXFLAGS_set" = set; then
BITCODE_CXXFLAGS=$ac_env_BITCODE_CXXFLAGS_value
else
2018-03-22 09:41:08 +08:00
BITCODE_CXXFLAGS="-O2 $BITCODE_CXXFLAGS"
2018-03-21 08:26:25 +08:00
fi
2018-03-21 06:41:15 +08:00
# C[XX]FLAGS we determined above will be added back at the end
2015-01-15 00:08:13 +08:00
user_CFLAGS=$CFLAGS
CFLAGS=""
2018-03-21 06:41:15 +08:00
user_CXXFLAGS=$CXXFLAGS
CXXFLAGS=""
2018-03-21 08:26:25 +08:00
user_BITCODE_CFLAGS=$BITCODE_CFLAGS
BITCODE_CFLAGS=""
user_BITCODE_CXXFLAGS=$BITCODE_CXXFLAGS
BITCODE_CXXFLAGS=""
2015-01-15 00:08:13 +08:00
2013-04-30 13:59:26 +08:00
# set CFLAGS_VECTOR from the environment, if available
if test "$ac_env_CFLAGS_VECTOR_set" = set; then
CFLAGS_VECTOR=$ac_env_CFLAGS_VECTOR_value
fi
2006-04-30 04:47:31 +08:00
# Some versions of GCC support some additional useful warning flags.
# Check whether they are supported, and add them to CFLAGS if so.
2009-02-12 04:02:40 +08:00
# ICC pretends to be GCC but it's lying; it doesn't support these flags,
# but has its own. Also check other compiler-specific flags here.
2004-10-20 10:12:07 +08:00
2007-08-05 23:43:00 +08:00
if test "$GCC" = yes -a "$ICC" = no; then
2015-01-15 00:08:13 +08:00
CFLAGS="-Wall -Wmissing-prototypes -Wpointer-arith"
2018-03-21 06:41:15 +08:00
CXXFLAGS="-Wall -Wpointer-arith"
2007-08-05 23:43:00 +08:00
# These work in some but not all gcc versions
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 23:20:33 +08:00
save_CFLAGS=$CFLAGS
2007-08-05 23:43:00 +08:00
PGAC_PROG_CC_CFLAGS_OPT([-Wdeclaration-after-statement])
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 23:20:33 +08:00
# -Wdeclaration-after-statement isn't applicable for C++. Specific C files
# disable it, so AC_SUBST the negative form.
PERMIT_DECLARATION_AFTER_STATEMENT=
2019-02-17 05:12:28 +08:00
if test x"$save_CFLAGS" != x"$CFLAGS"; then
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 23:20:33 +08:00
PERMIT_DECLARATION_AFTER_STATEMENT=-Wno-declaration-after-statement
fi
AC_SUBST(PERMIT_DECLARATION_AFTER_STATEMENT)
2018-08-24 09:33:40 +08:00
# Really don't want VLAs to be used in our dialect of C
PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])
# -Wvla is not applicable for C++
2007-08-05 23:43:00 +08:00
PGAC_PROG_CC_CFLAGS_OPT([-Wendif-labels])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-Wendif-labels])
2011-09-11 04:12:46 +08:00
PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-Wmissing-format-attribute])
2011-01-27 07:23:48 +08:00
# This was included in -Wall/-Wformat in older GCC versions
PGAC_PROG_CC_CFLAGS_OPT([-Wformat-security])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-Wformat-security])
2004-10-20 10:12:07 +08:00
# Disable strict-aliasing rules; needed for gcc 3.3+
PGAC_PROG_CC_CFLAGS_OPT([-fno-strict-aliasing])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-fno-strict-aliasing])
2008-03-11 05:50:16 +08:00
# Disable optimizations that assume no overflow; needed for gcc 4.3+
PGAC_PROG_CC_CFLAGS_OPT([-fwrapv])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-fwrapv])
2011-12-15 06:15:24 +08:00
# Disable FP optimizations that cause various errors on gcc 4.5+ or maybe 4.6+
PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-fexcess-precision=standard])
2013-04-30 13:59:26 +08:00
# Optimization flags for specific files that benefit from vectorization
PGAC_PROG_CC_VAR_OPT(CFLAGS_VECTOR, [-funroll-loops])
PGAC_PROG_CC_VAR_OPT(CFLAGS_VECTOR, [-ftree-vectorize])
2015-04-06 01:01:55 +08:00
# We want to suppress clang's unhelpful unused-command-line-argument warnings
# but gcc won't complain about unrecognized -Wno-foo switches, so we have to
# test for the positive form and if that works, add the negative form
2018-06-17 03:34:07 +08:00
NOT_THE_CFLAGS=""
2015-04-06 01:01:55 +08:00
PGAC_PROG_CC_VAR_OPT(NOT_THE_CFLAGS, [-Wunused-command-line-argument])
if test -n "$NOT_THE_CFLAGS"; then
CFLAGS="$CFLAGS -Wno-unused-command-line-argument"
fi
2018-06-17 03:34:07 +08:00
# Similarly disable useless truncation warnings from gcc 8+
NOT_THE_CFLAGS=""
PGAC_PROG_CC_VAR_OPT(NOT_THE_CFLAGS, [-Wformat-truncation])
if test -n "$NOT_THE_CFLAGS"; then
CFLAGS="$CFLAGS -Wno-format-truncation"
fi
NOT_THE_CFLAGS=""
PGAC_PROG_CC_VAR_OPT(NOT_THE_CFLAGS, [-Wstringop-truncation])
if test -n "$NOT_THE_CFLAGS"; then
CFLAGS="$CFLAGS -Wno-stringop-truncation"
fi
2007-08-05 23:43:00 +08:00
elif test "$ICC" = yes; then
# Intel's compiler has a bug/misoptimization in checking for
# division by NAN (NaN == 0), -mp1 fixes it, so add it to the CFLAGS.
PGAC_PROG_CC_CFLAGS_OPT([-mp1])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-mp1])
2007-09-12 22:28:55 +08:00
# Make sure strict aliasing is off (though this is said to be the default)
PGAC_PROG_CC_CFLAGS_OPT([-fno-strict-aliasing])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-fno-strict-aliasing])
2009-02-12 04:02:40 +08:00
elif test "$PORTNAME" = "aix"; then
# AIX's xlc has to have strict aliasing turned off too
2006-04-27 22:27:04 +08:00
PGAC_PROG_CC_CFLAGS_OPT([-qnoansialias])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-qnoansialias])
2015-07-17 15:01:14 +08:00
PGAC_PROG_CC_CFLAGS_OPT([-qlonglong])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([-qlonglong])
2011-05-27 05:29:33 +08:00
elif test "$PORTNAME" = "hpux"; then
# On some versions of HP-UX, libm functions do not set errno by default.
# Fix that by using +Olibmerrno if the compiler recognizes it.
PGAC_PROG_CC_CFLAGS_OPT([+Olibmerrno])
2018-03-21 06:41:15 +08:00
PGAC_PROG_CXX_CFLAGS_OPT([+Olibmerrno])
2004-10-20 10:12:07 +08:00
fi
2003-10-25 23:32:11 +08:00
2019-10-22 00:32:35 +08:00
AC_SUBST(CFLAGS_VECTOR)
2013-04-30 13:59:26 +08:00
2018-03-21 08:26:25 +08:00
# Determine flags used to emit bitcode for JIT inlining. Need to test
# for behaviour changing compiler flags, to keep compatibility with
# compiler used for normal postgres code.
if test "$with_llvm" = yes ; then
CLANGXX="$CLANG -xc++"
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fno-strict-aliasing])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-fno-strict-aliasing])
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fwrapv])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-fwrapv])
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fexcess-precision=standard])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-fexcess-precision=standard])
fi
2003-10-16 06:23:56 +08:00
# supply -g if --enable-debug
2003-11-02 04:48:51 +08:00
if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then
2003-10-16 06:23:56 +08:00
CFLAGS="$CFLAGS -g"
fi
2003-10-25 23:32:11 +08:00
2018-03-21 06:41:15 +08:00
if test "$enable_debug" = yes && test "$ac_cv_prog_cxx_g" = yes; then
CXXFLAGS="$CXXFLAGS -g"
fi
2008-09-05 20:11:18 +08:00
# enable code coverage if --enable-coverage
if test "$enable_coverage" = yes; then
if test "$GCC" = yes; then
CFLAGS="$CFLAGS -fprofile-arcs -ftest-coverage"
2018-03-21 06:41:15 +08:00
CXXFLAGS="$CXXFLAGS -fprofile-arcs -ftest-coverage"
2008-09-05 20:11:18 +08:00
else
AC_MSG_ERROR([--enable-coverage is supported only when using GCC])
fi
fi
2007-02-21 23:12:39 +08:00
# enable profiling if --enable-profiling
if test "$enable_profiling" = yes && test "$ac_cv_prog_cc_g" = yes; then
if test "$GCC" = yes; then
2010-11-24 04:27:50 +08:00
AC_DEFINE([PROFILE_PID_DIR], 1,
2007-09-21 10:33:46 +08:00
[Define to 1 to allow profiling output to be saved separately for each process.])
CFLAGS="$CFLAGS -pg $PLATFORM_PROFILE_FLAGS"
2018-03-21 06:41:15 +08:00
CXXFLAGS="$CXXFLAGS -pg $PLATFORM_PROFILE_FLAGS"
2007-02-21 23:12:39 +08:00
else
AC_MSG_ERROR([--enable-profiling is supported only when using GCC])
fi
fi
2003-09-07 11:43:57 +08:00
# We already have this in Makefile.win32, but configure needs it too
2003-10-25 23:32:11 +08:00
if test "$PORTNAME" = "win32"; then
2004-02-03 00:00:49 +08:00
CPPFLAGS="$CPPFLAGS -I$srcdir/src/include/port/win32 -DEXEC_BACKEND"
2003-09-07 11:43:57 +08:00
fi
2018-03-21 06:41:15 +08:00
# Now that we're done automatically adding stuff to C[XX]FLAGS, put back the
2015-01-15 00:08:13 +08:00
# user-specified flags (if any) at the end. This lets users override
# the automatic additions.
CFLAGS="$CFLAGS $user_CFLAGS"
2018-03-21 06:41:15 +08:00
CXXFLAGS="$CXXFLAGS $user_CXXFLAGS"
2018-03-21 08:26:25 +08:00
BITCODE_CFLAGS="$BITCODE_CFLAGS $user_BITCODE_CFLAGS"
BITCODE_CXXFLAGS="$BITCODE_CXXFLAGS $user_BITCODE_CXXFLAGS"
2019-10-22 00:32:35 +08:00
AC_SUBST(BITCODE_CFLAGS)
AC_SUBST(BITCODE_CXXFLAGS)
# The template file must set up CFLAGS_SL; we don't support user override
AC_SUBST(CFLAGS_SL)
2015-01-15 00:08:13 +08:00
# Check if the compiler still works with the final flag settings
2018-03-21 06:41:15 +08:00
# (note, we're not checking that for CXX, which is optional)
2002-03-30 01:32:55 +08:00
AC_MSG_CHECKING([whether the C compiler still works])
2015-07-03 00:21:23 +08:00
AC_LINK_IFELSE([AC_LANG_PROGRAM([], [return 0;])],
2002-03-30 01:32:55 +08:00
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
AC_MSG_ERROR([cannot proceed])])
2002-09-21 02:38:57 +08:00
2003-10-16 06:23:56 +08:00
# Defend against gcc -ffast-math
2002-09-21 02:38:57 +08:00
if test "$GCC" = yes; then
2015-07-03 00:21:23 +08:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@ifdef __FAST_MATH__
2002-09-21 02:38:57 +08:00
choke me
2015-07-03 00:21:23 +08:00
@%:@endif])], [], [AC_MSG_ERROR([do not put -ffast-math in CFLAGS])])
2002-09-21 02:38:57 +08:00
fi
Error out for clang on x86-32 without SSE2 support, no -fexcess-precision.
As clang currently doesn't support -fexcess-precision=standard,
compiling x86-32 code with SSE2 disabled, can lead to problems with
floating point overflow checks and the like.
This issue was noticed because clang, on at least some BSDs, defaults
to i386 compatibility, whereas it defaults to pentium4 on Linux. Our
forced usage of __builtin_isinf() lead to some overflow checks not
triggering when compiling for i386, e.g. when the result of the
calculation didn't overflow in 80bit registers, but did so in 64bit.
While we could just fall back to a non-builtin isinf, it seems likely
that the use of 80bit registers leads to other problems (which is why
we force the flag for GCC already). Therefore error out when
detecting clang in that situation.
Reported-By: Victor Wagner
Analyzed-By: Andrew Gierth and Andres Freund
Author: Andres Freund
Discussion: https://postgr.es/m/20180905005130.ewk4xcs5dgyzcy45@alap3.anarazel.de
Backpatch: 9.3-, all supported versions are affected
2018-09-14 05:18:43 +08:00
# Defend against clang being used on x86-32 without SSE2 enabled. As current
# versions of clang do not understand -fexcess-precision=standard, the use of
# x87 floating point operations leads to problems like isinf possibly returning
# false for a value that is infinite when converted from the 80bit register to
# the 8byte memory representation.
#
# Only perform the test if the compiler doesn't understand
# -fexcess-precision=standard, that way a potentially fixed compiler will work
# automatically.
if test "$pgac_cv_prog_CC_cflags__fexcess_precision_standard" = no; then
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [
@%:@if defined(__clang__) && defined(__i386__) && !defined(__SSE2_MATH__)
choke me
@%:@endif
])], [],
[AC_MSG_ERROR([Compiling PostgreSQL with clang, on 32bit x86, requires SSE2 support. Use -msse2 or use gcc.])])
fi
2000-06-10 11:16:34 +08:00
AC_PROG_CPP
2000-06-11 19:40:09 +08:00
AC_SUBST(GCC)
2000-06-10 11:16:34 +08:00
2003-12-24 02:40:53 +08:00
#
# Set up TAS assembly code if needed; the template file has now had its
# chance to request this.
#
AC_CONFIG_LINKS([src/backend/port/tas.s:src/backend/port/tas/${tas_file}])
if test "$need_tas" = yes ; then
TAS=tas.o
else
TAS=""
fi
AC_SUBST(TAS)
2000-07-16 22:50:44 +08:00
#
# Automatic dependency tracking
#
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(enable, depend, no, [turn on automatic dependency tracking],
2000-09-22 04:17:43 +08:00
[autodepend=yes])
2000-07-16 22:50:44 +08:00
AC_SUBST(autodepend)
2000-09-22 04:17:43 +08:00
#
# Enable assert checks
#
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(enable, cassert, no, [enable assertion checks (for debugging)],
2000-09-22 04:17:43 +08:00
[AC_DEFINE([USE_ASSERT_CHECKING], 1,
2003-04-07 06:45:23 +08:00
[Define to 1 to build with assertion checks. (--enable-cassert)])])
2000-07-15 23:54:52 +08:00
#
# Include directories
#
ac_save_IFS=$IFS
2004-09-02 23:39:56 +08:00
IFS="${IFS}${PATH_SEPARATOR}"
2000-07-15 23:54:52 +08:00
# SRCH_INC comes from the template file
for dir in $with_includes $SRCH_INC; do
if test -d "$dir"; then
INCLUDES="$INCLUDES -I$dir"
else
AC_MSG_WARN([*** Include directory $dir does not exist.])
fi
done
IFS=$ac_save_IFS
AC_SUBST(INCLUDES)
#
# Library directories
#
ac_save_IFS=$IFS
2004-09-02 23:39:56 +08:00
IFS="${IFS}${PATH_SEPARATOR}"
2000-07-15 23:54:52 +08:00
# LIBRARY_DIRS comes from command line, SRCH_LIB from template file.
for dir in $LIBRARY_DIRS $SRCH_LIB; do
if test -d "$dir"; then
2000-10-26 00:13:52 +08:00
LIBDIRS="$LIBDIRS -L$dir"
2000-07-15 23:54:52 +08:00
else
AC_MSG_WARN([*** Library directory $dir does not exist.])
fi
done
IFS=$ac_save_IFS
2003-06-14 07:10:08 +08:00
#
2003-08-12 02:07:38 +08:00
# Enable thread-safe client libraries
2003-06-14 07:10:08 +08:00
#
2003-08-12 02:07:38 +08:00
AC_MSG_CHECKING([allow thread-safe client libraries])
2009-12-02 22:07:26 +08:00
PGAC_ARG_BOOL(enable, thread-safety, yes, [disable thread-safety in client libraries])
2009-12-11 10:21:21 +08:00
if test "$enable_thread_safety" = yes; then
AC_DEFINE([ENABLE_THREAD_SAFETY], 1,
[Define to 1 to build client libraries as thread-safe code. (--enable-thread-safety)])
fi
2003-08-01 11:10:04 +08:00
AC_MSG_RESULT([$enable_thread_safety])
AC_SUBST(enable_thread_safety)
2003-06-14 07:10:08 +08:00
2017-03-24 03:25:34 +08:00
#
# ICU
#
AC_MSG_CHECKING([whether to build with ICU support])
PGAC_ARG_BOOL(with, icu, no, [build with ICU support],
[AC_DEFINE([USE_ICU], 1, [Define to build with ICU support. (--with-icu)])])
AC_MSG_RESULT([$with_icu])
AC_SUBST(with_icu)
if test "$with_icu" = yes; then
PKG_CHECK_MODULES(ICU, icu-uc icu-i18n)
fi
2000-09-26 06:23:01 +08:00
#
2004-10-01 10:00:44 +08:00
# Optionally build Tcl modules (PL/Tcl)
2000-09-26 06:23:01 +08:00
#
AC_MSG_CHECKING([whether to build with Tcl])
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(with, tcl, no, [build Tcl modules (PL/Tcl)])
2000-09-26 06:23:01 +08:00
AC_MSG_RESULT([$with_tcl])
AC_SUBST([with_tcl])
2002-03-30 01:32:55 +08:00
# We see if the path to the Tcl/Tk configuration scripts is specified.
2000-09-22 04:17:43 +08:00
# This will override the use of tclsh to find the paths to search.
1998-10-18 12:16:08 +08:00
2008-10-29 17:27:24 +08:00
PGAC_ARG_REQ(with, tclconfig, [DIR], [tclConfig.sh is in DIR])
2000-09-22 04:17:43 +08:00
2002-08-31 00:23:21 +08:00
#
2002-09-05 06:54:18 +08:00
# Optionally build Perl modules (PL/Perl)
2002-08-31 00:23:21 +08:00
#
AC_MSG_CHECKING([whether to build Perl modules])
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(with, perl, no, [build Perl modules (PL/Perl)])
2002-08-31 00:23:21 +08:00
AC_MSG_RESULT([$with_perl])
AC_SUBST(with_perl)
2000-09-22 04:17:43 +08:00
#
2003-09-02 07:01:49 +08:00
# Optionally build Python modules (PL/Python)
2000-09-22 04:17:43 +08:00
#
AC_MSG_CHECKING([whether to build Python modules])
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(with, python, no, [build Python modules (PL/Python)])
2001-05-13 01:49:32 +08:00
AC_MSG_RESULT([$with_python])
2000-06-11 02:02:12 +08:00
AC_SUBST(with_python)
1998-04-06 04:28:23 +08:00
2007-07-10 21:14:22 +08:00
#
# GSSAPI
#
2007-07-11 00:41:01 +08:00
AC_MSG_CHECKING([whether to build with GSSAPI support])
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(with, gssapi, no, [build with GSSAPI support],
2007-07-10 21:14:22 +08:00
[
AC_DEFINE(ENABLE_GSS, 1, [Define to build with GSSAPI support. (--with-gssapi)])
krb_srvtab="FILE:\$(sysconfdir)/krb5.keytab"
])
AC_MSG_RESULT([$with_gssapi])
2018-03-06 03:42:11 +08:00
AC_SUBST(with_gssapi)
2007-07-10 21:14:22 +08:00
2000-07-09 21:14:19 +08:00
2000-08-25 18:00:35 +08:00
AC_SUBST(krb_srvtab)
2000-06-17 08:10:40 +08:00
2000-07-09 21:14:19 +08:00
#
# Kerberos configuration parameters
#
2000-09-22 04:17:43 +08:00
PGAC_ARG_REQ(with, krb-srvnam,
2014-01-16 00:24:01 +08:00
[NAME], [default service principal name in Kerberos (GSSAPI) [postgres]],
2000-09-22 04:17:43 +08:00
[],
[with_krb_srvnam="postgres"])
2018-03-06 03:42:11 +08:00
AC_SUBST(with_krb_srvnam)
2000-09-22 04:17:43 +08:00
AC_DEFINE_UNQUOTED([PG_KRB_SRVNAM], ["$with_krb_srvnam"],
2014-01-16 00:24:01 +08:00
[Define to the name of the default PostgreSQL service principal in Kerberos (GSSAPI). (--with-krb-srvnam=NAME)])
2000-06-17 08:10:40 +08:00
2001-09-06 11:23:38 +08:00
#
# PAM
#
AC_MSG_CHECKING([whether to build with PAM support])
2001-12-14 06:00:22 +08:00
PGAC_ARG_BOOL(with, pam, no,
2008-10-29 17:27:24 +08:00
[build with PAM support],
2003-04-07 06:45:23 +08:00
[AC_DEFINE([USE_PAM], 1, [Define to 1 to build with PAM support. (--with-pam)])])
2001-12-14 06:00:22 +08:00
AC_MSG_RESULT([$with_pam])
2001-09-06 11:23:38 +08:00
2000-06-17 08:10:40 +08:00
2016-04-09 01:51:54 +08:00
#
# BSD AUTH
#
AC_MSG_CHECKING([whether to build with BSD Authentication support])
PGAC_ARG_BOOL(with, bsd-auth, no,
[build with BSD Authentication support],
[AC_DEFINE([USE_BSD_AUTH], 1, [Define to 1 to build with BSD Authentication support. (--with-bsd-auth)])])
AC_MSG_RESULT([$with_bsd_auth])
2006-03-07 01:41:44 +08:00
#
# LDAP
#
AC_MSG_CHECKING([whether to build with LDAP support])
PGAC_ARG_BOOL(with, ldap, no,
2008-10-29 17:27:24 +08:00
[build with LDAP support],
2006-03-07 01:41:44 +08:00
[AC_DEFINE([USE_LDAP], 1, [Define to 1 to build with LDAP support. (--with-ldap)])])
AC_MSG_RESULT([$with_ldap])
2018-03-03 14:29:51 +08:00
AC_SUBST(with_ldap)
2006-03-07 01:41:44 +08:00
2003-06-11 14:56:07 +08:00
#
2005-05-15 08:26:19 +08:00
# Bonjour
2003-06-11 14:56:07 +08:00
#
2005-05-15 08:26:19 +08:00
AC_MSG_CHECKING([whether to build with Bonjour support])
PGAC_ARG_BOOL(with, bonjour, no,
2008-10-29 17:27:24 +08:00
[build with Bonjour support],
2005-05-15 08:26:19 +08:00
[AC_DEFINE([USE_BONJOUR], 1, [Define to 1 to build with Bonjour support. (--with-bonjour)])])
AC_MSG_RESULT([$with_bonjour])
2003-06-11 14:56:07 +08:00
2000-07-09 21:14:19 +08:00
#
# OpenSSL
#
2003-11-28 03:44:56 +08:00
AC_MSG_CHECKING([whether to build with OpenSSL support])
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(with, openssl, no, [build with OpenSSL support],
Break out OpenSSL-specific code to separate files.
This refactoring is in preparation for adding support for other SSL
implementations, with no user-visible effects. There are now two #defines,
USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
is defined when building with any SSL implementation. Currently, OpenSSL is
the only implementation so the two #defines go together, but USE_SSL is
supposed to be used for implementation-independent code.
The libpq SSL code is changed to use a custom BIO, which does all the raw
I/O, like we've been doing in the backend for a long time. That makes it
possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
a couple of syscall for each send(). Probably doesn't make much performance
difference in practice - the SSL encryption is expensive enough to mask the
effect - but it was a natural result of this refactoring.
Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
Alvaro Herrera, Andreas Karlsson, Jeff Janes.
2014-08-11 16:54:19 +08:00
[AC_DEFINE([USE_OPENSSL], 1, [Define to build with OpenSSL support. (--with-openssl)])])
2003-11-28 03:44:56 +08:00
AC_MSG_RESULT([$with_openssl])
2000-09-22 04:17:43 +08:00
AC_SUBST(with_openssl)
2000-07-09 21:14:19 +08:00
2011-01-24 09:44:48 +08:00
#
# SELinux
#
AC_MSG_CHECKING([whether to build with SELinux support])
PGAC_ARG_BOOL(with, selinux, no, [build with SELinux support])
AC_SUBST(with_selinux)
AC_MSG_RESULT([$with_selinux])
2000-07-09 21:14:19 +08:00
2015-11-17 19:46:17 +08:00
#
# Systemd
#
AC_MSG_CHECKING([whether to build with systemd support])
PGAC_ARG_BOOL(with, systemd, no, [build with systemd support],
[AC_DEFINE([USE_SYSTEMD], 1, [Define to build with systemd support. (--with-systemd)])])
AC_SUBST(with_systemd)
AC_MSG_RESULT([$with_systemd])
2002-04-11 06:47:09 +08:00
#
# Readline
#
PGAC_ARG_BOOL(with, readline, yes,
2008-10-29 17:27:24 +08:00
[do not use GNU Readline nor BSD Libedit for editing])
2004-07-21 04:37:13 +08:00
# readline on MinGW has problems with backslashes in psql and other bugs.
# This is particularly a problem with non-US code pages.
# Therefore disable its use until we understand the cause. 2004-07-20
2004-09-10 21:53:40 +08:00
if test "$PORTNAME" = "win32"; then
2004-07-21 04:37:13 +08:00
if test "$with_readline" = yes; then
AC_MSG_WARN([*** Readline does not work on MinGW --- disabling])
with_readline=no
2004-09-10 21:53:40 +08:00
fi
fi
2020-01-03 04:02:21 +08:00
AC_SUBST(with_readline)
2004-07-21 04:37:13 +08:00
2002-04-11 06:47:09 +08:00
2006-10-02 07:47:16 +08:00
#
# Prefer libedit
#
PGAC_ARG_BOOL(with, libedit-preferred, no,
2008-10-29 17:27:24 +08:00
[prefer BSD Libedit over GNU Readline])
2006-10-02 07:47:16 +08:00
2007-04-22 01:26:18 +08:00
#
2014-05-28 07:42:08 +08:00
# UUID library
2007-04-22 01:26:18 +08:00
#
2014-05-28 07:42:08 +08:00
# There are at least three UUID libraries in common use: the FreeBSD/NetBSD
# library, the e2fsprogs libuuid (now part of util-linux-ng), and the OSSP
# UUID library. More than one of these might be present on a given platform,
# so we make the user say which one she wants.
#
PGAC_ARG_REQ(with, uuid, [LIB], [build contrib/uuid-ossp using LIB (bsd,e2fs,ossp)])
if test x"$with_uuid" = x"" ; then
with_uuid=no
fi
PGAC_ARG_BOOL(with, ossp-uuid, no, [obsolete spelling of --with-uuid=ossp])
if test "$with_ossp_uuid" = yes ; then
with_uuid=ossp
fi
if test "$with_uuid" = bsd ; then
AC_DEFINE([HAVE_UUID_BSD], 1, [Define to 1 if you have BSD UUID support.])
UUID_EXTRA_OBJS="md5.o sha1.o"
elif test "$with_uuid" = e2fs ; then
AC_DEFINE([HAVE_UUID_E2FS], 1, [Define to 1 if you have E2FS UUID support.])
UUID_EXTRA_OBJS="md5.o sha1.o"
elif test "$with_uuid" = ossp ; then
AC_DEFINE([HAVE_UUID_OSSP], 1, [Define to 1 if you have OSSP UUID support.])
UUID_EXTRA_OBJS=""
elif test "$with_uuid" = no ; then
UUID_EXTRA_OBJS=""
else
AC_MSG_ERROR([--with-uuid must specify one of bsd, e2fs, or ossp])
fi
AC_SUBST(with_uuid)
AC_SUBST(UUID_EXTRA_OBJS)
2007-04-22 01:26:18 +08:00
2006-12-22 00:05:16 +08:00
#
# XML
#
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(with, libxml, no, [build with XML support],
2006-12-22 00:05:16 +08:00
[AC_DEFINE([USE_LIBXML], 1, [Define to 1 to build with XML support. (--with-libxml)])])
2007-01-18 22:07:31 +08:00
if test "$with_libxml" = yes ; then
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
PGAC_PATH_PROGS(XML2_CONFIG, xml2-config)
2019-01-18 15:29:42 +08:00
AC_ARG_VAR(XML2_CONFIG, [path to xml2-config utility])dnl
2007-01-18 22:07:31 +08:00
if test -n "$XML2_CONFIG"; then
for pgac_option in `$XML2_CONFIG --cflags`; do
case $pgac_option in
-I*|-D*) CPPFLAGS="$CPPFLAGS $pgac_option";;
esac
done
for pgac_option in `$XML2_CONFIG --libs`; do
case $pgac_option in
-L*) LDFLAGS="$LDFLAGS $pgac_option";;
esac
done
fi
fi
2007-04-14 02:50:01 +08:00
AC_SUBST(with_libxml)
2006-12-22 00:05:16 +08:00
2007-04-15 20:48:24 +08:00
#
# XSLT
#
2008-10-29 17:27:24 +08:00
PGAC_ARG_BOOL(with, libxslt, no, [use XSLT support when building contrib/xml2],
2008-01-24 14:23:33 +08:00
[AC_DEFINE([USE_LIBXSLT], 1, [Define to 1 to use XSLT support when building contrib/xml2. (--with-libxslt)])])
2007-04-15 20:48:24 +08:00
AC_SUBST(with_libxslt)
2007-08-20 16:53:12 +08:00
#
# tzdata
#
PGAC_ARG_REQ(with, system-tzdata,
2008-10-29 17:27:24 +08:00
[DIR], [use system time zone data in DIR])
2007-08-20 16:53:12 +08:00
AC_SUBST(with_system_tzdata)
2002-04-11 06:47:09 +08:00
#
# Zlib
#
PGAC_ARG_BOOL(with, zlib, yes,
2008-10-29 17:27:24 +08:00
[do not use Zlib])
2005-07-06 07:13:57 +08:00
AC_SUBST(with_zlib)
2002-04-11 06:47:09 +08:00
2003-05-28 00:36:50 +08:00
#
# Assignments
#
2000-03-30 13:29:21 +08:00
2000-07-15 23:54:52 +08:00
CPPFLAGS="$CPPFLAGS $INCLUDES"
2000-10-26 00:13:52 +08:00
LDFLAGS="$LDFLAGS $LIBDIRS"
2000-07-15 23:54:52 +08:00
2010-07-06 02:54:38 +08:00
AC_ARG_VAR(LDFLAGS_EX, [extra linker flags for linking executables only])
AC_ARG_VAR(LDFLAGS_SL, [extra linker flags for linking shared libraries only])
2000-07-15 23:54:52 +08:00
2004-07-18 02:53:56 +08:00
PGAC_PROG_LD
2000-10-25 01:41:50 +08:00
AC_SUBST(LD)
AC_SUBST(with_gnu_ld)
1997-02-04 16:53:45 +08:00
AC_PROG_RANLIB
2002-04-11 00:45:25 +08:00
PGAC_CHECK_STRIP
2008-12-07 16:36:22 +08:00
AC_CHECK_TOOL(AR, ar, ar)
if test "$PORTNAME" = "win32"; then
AC_CHECK_TOOL(DLLTOOL, dlltool, dlltool)
AC_CHECK_TOOL(DLLWRAP, dllwrap, dllwrap)
AC_CHECK_TOOL(WINDRES, windres, windres)
fi
2001-02-11 06:31:42 +08:00
2012-06-27 18:40:51 +08:00
AC_PROG_INSTALL
# When Autoconf chooses install-sh as install program it tries to generate
2017-02-06 17:33:58 +08:00
# a relative path to it in each makefile where it substitutes it. This clashes
2012-06-27 18:40:51 +08:00
# with our Makefile.global concept. This workaround helps.
case $INSTALL in
2012-06-29 01:05:36 +08:00
*install-sh*) install_bin='';;
*) install_bin=$INSTALL;;
2012-06-27 18:40:51 +08:00
esac
2012-06-29 01:05:36 +08:00
AC_SUBST(install_bin)
2012-06-27 18:40:51 +08:00
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
PGAC_PATH_PROGS(TAR, tar)
2007-07-20 01:15:30 +08:00
AC_PROG_LN_S
2009-08-27 06:24:44 +08:00
AC_PROG_MKDIR_P
# When Autoconf chooses install-sh as mkdir -p program it tries to generate
2017-02-06 17:33:58 +08:00
# a relative path to it in each makefile where it substitutes it. This clashes
2009-08-27 06:24:44 +08:00
# with our Makefile.global concept. This workaround helps.
case $MKDIR_P in
*install-sh*) MKDIR_P='\${SHELL} \${top_srcdir}/config/install-sh -c -d';;
esac
2003-06-07 03:11:55 +08:00
2008-08-29 21:02:33 +08:00
PGAC_PATH_BISON
2007-07-20 01:15:30 +08:00
PGAC_PATH_FLEX
2001-02-11 06:31:42 +08:00
2002-08-31 00:23:21 +08:00
PGAC_PATH_PERL
if test "$with_perl" = yes; then
2010-01-07 11:24:57 +08:00
if test -z "$PERL"; then
AC_MSG_ERROR([Perl not found])
fi
2002-09-05 06:54:18 +08:00
PGAC_CHECK_PERL_CONFIGS([archlibexp,privlibexp,useshrplib])
Move interpreter shared library detection to configure
For building PL/Perl, PL/Python, and PL/Tcl, we need a shared library of
libperl, libpython, and libtcl, respectively. Previously, this was
checked in the makefiles, skipping the PL build with a warning if no
shared library was available. Now this is checked in configure, with an
error if no shared library is available.
The previous situation arose because in the olden days, the configure
options --with-perl, --with-python, and --with-tcl controlled whether
frontend interfaces for those languages would be built. The procedural
languages were added later, and shared libraries were often not
available in the beginning. So it was decided skip the builds of the
procedural languages in those cases. The frontend interfaces have since
been removed from the tree, and shared libraries are now available most
of the time, so that setup makes much less sense now.
Also, the new setup allows contrib modules and pgxs users to rely on the
respective PLs being available based on configure flags.
2015-05-02 09:38:21 +08:00
if test "$perl_useshrplib" != yes && test "$perl_useshrplib" != true; then
AC_MSG_ERROR([cannot build PL/Perl because libperl is not a shared library
You might have to rebuild your Perl installation. Refer to the
documentation for details. Use --without-perl to disable building
PL/Perl.])
fi
2018-09-26 01:23:29 +08:00
# On most platforms, archlibexp is also where the Perl include files live ...
Still further rethinking of build changes for macOS Mojave.
To avoid the sorts of problems complained of by Jakob Egger, it'd be
best if configure didn't emit any references to the sysroot path at all.
In the case of PL/Tcl, we can do that just by keeping our hands off the
TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to
substitute -iwithsysroot for -I in the compile commands, which is easily
handled if we change to using a configure output variable that includes
the switch not only the directory name. Since PL/Tcl and PL/Python
already do it like that, this seems like good consistency cleanup anyway.
Hence, this replaces the advice given to Perl-related extensions in commit
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should
just write "$(perl_includespec)". (The old way continues to work, but not
on recent macOS.)
It's still the case that configure needs to be aware of the sysroot
path internally, but that's cleaner than what we had before.
As before, back-patch to all supported versions.
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
2018-10-19 02:55:23 +08:00
perl_includespec="-I$perl_archlibexp/CORE"
# ... but on newer macOS versions, we must use -iwithsysroot to look
# under $PG_SYSROOT
if test \! -f "$perl_archlibexp/CORE/perl.h" ; then
2018-10-17 04:27:15 +08:00
if test -f "$PG_SYSROOT$perl_archlibexp/CORE/perl.h" ; then
Still further rethinking of build changes for macOS Mojave.
To avoid the sorts of problems complained of by Jakob Egger, it'd be
best if configure didn't emit any references to the sysroot path at all.
In the case of PL/Tcl, we can do that just by keeping our hands off the
TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to
substitute -iwithsysroot for -I in the compile commands, which is easily
handled if we change to using a configure output variable that includes
the switch not only the directory name. Since PL/Tcl and PL/Python
already do it like that, this seems like good consistency cleanup anyway.
Hence, this replaces the advice given to Perl-related extensions in commit
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should
just write "$(perl_includespec)". (The old way continues to work, but not
on recent macOS.)
It's still the case that configure needs to be aware of the sysroot
path internally, but that's cleaner than what we had before.
As before, back-patch to all supported versions.
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
2018-10-19 02:55:23 +08:00
perl_includespec="-iwithsysroot $perl_archlibexp/CORE"
2018-09-26 01:23:29 +08:00
fi
fi
Still further rethinking of build changes for macOS Mojave.
To avoid the sorts of problems complained of by Jakob Egger, it'd be
best if configure didn't emit any references to the sysroot path at all.
In the case of PL/Tcl, we can do that just by keeping our hands off the
TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to
substitute -iwithsysroot for -I in the compile commands, which is easily
handled if we change to using a configure output variable that includes
the switch not only the directory name. Since PL/Tcl and PL/Python
already do it like that, this seems like good consistency cleanup anyway.
Hence, this replaces the advice given to Perl-related extensions in commit
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should
just write "$(perl_includespec)". (The old way continues to work, but not
on recent macOS.)
It's still the case that configure needs to be aware of the sysroot
path internally, but that's cleaner than what we had before.
As before, back-patch to all supported versions.
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
2018-10-19 02:55:23 +08:00
AC_SUBST(perl_includespec)dnl
PL/Perl portability fix: absorb relevant -D switches from Perl.
The Perl documentation is very clear that stuff calling libperl should
be built with the compiler switches shown by Perl's $Config{ccflags}.
We'd been ignoring that up to now, and mostly getting away with it,
but recent Perl versions contain ABI compatibility cross-checks that
fail on some builds because of this omission. In particular the
sizeof(PerlInterpreter) can come out different due to some fields being
added or removed; which means we have a live ABI hazard that we'd better
fix rather than continuing to sweep it under the rug.
However, it still seems like a bad idea to just absorb $Config{ccflags}
verbatim. In some environments Perl was built with a different compiler
that doesn't even use the same switch syntax. -D switch syntax is pretty
universal though, and absorbing Perl's -D switches really ought to be
enough to fix the problem.
Furthermore, Perl likes to inject stuff like -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64 into $Config{ccflags}, which affect libc ABIs on
platforms where they're relevant. Adopting those seems dangerous too.
It's unclear whether a build wherein Perl and Postgres have different ideas
of sizeof(off_t) etc would work, or whether anyone would care about making
it work. But it's dead certain that having different stdio ABIs in
core Postgres and PL/Perl will not work; we've seen that movie before.
Therefore, let's also ignore -D switches for symbols beginning with
underscore. The symbols that we actually need to import should be the ones
mentioned in perl.h's PL_bincompat_options stanza, and none of those start
with underscore, so this seems likely to work. (If it turns out not to
work everywhere, we could consider intersecting the symbols mentioned in
PL_bincompat_options with the -D switches. But that will be much more
complicated, so let's try this way first.)
This will need to be back-patched, but first let's see what the
buildfarm makes of it.
Ashutosh Sharma, some adjustments by me
Discussion: https://postgr.es/m/CANFyU97OVQ3+Mzfmt3MhuUm5NwPU=-FtbNH5Eb7nZL9ua8=rcA@mail.gmail.com
2017-07-29 02:25:28 +08:00
PGAC_CHECK_PERL_EMBED_CCFLAGS
2002-08-31 00:23:21 +08:00
PGAC_CHECK_PERL_EMBED_LDFLAGS
fi
2001-05-13 01:49:32 +08:00
if test "$with_python" = yes; then
PGAC_PATH_PYTHON
PGAC_CHECK_PYTHON_EMBED_SETUP
fi
2009-01-05 18:25:59 +08:00
if test "$cross_compiling" = yes && test -z "$with_system_tzdata"; then
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
PGAC_PATH_PROGS(ZIC, zic)
2009-01-05 18:25:59 +08:00
if test -z "$ZIC"; then
AC_MSG_ERROR([
When cross-compiling, either use the option --with-system-tzdata to use
existing time-zone data, or set the environment variable ZIC to a zic
program to use during the build.])
fi
fi
2015-07-09 05:05:45 +08:00
#
# Pthreads
#
# For each platform, we need to know about any special compile and link
# libraries, and whether the normal C function names are thread-safe.
# See the comment at the top of src/port/thread.c for more information.
# WIN32 doesn't need the pthread tests; it always uses threads
#
# These tests are run before the library-tests, because linking with the
# other libraries can pull in the pthread functions as a side-effect. We
# want to use the -pthread or similar flags directly, and not rely on
# the side-effects of linking with some other library.
2019-02-09 22:55:17 +08:00
dnl note: We have to use AS_IF here rather than plain if. The AC_CHECK_HEADER
dnl invocation below is the first one in the script, and autoconf generates
dnl additional code for that, which must not be inside the if-block. AS_IF
dnl knows how to do that.
Use AS_IF rather than plain shell "if" in pthread-check.
Autoconf generates additional code for the first AC_CHECK_HEADERS call in
the script. If the first call is within an if-block, the additional code is
put inside the if-block too, even though it is needed by subsequent
AC_CHECK_HEADERS checks and should always be executed. When I moved the
pthread-related checks earlier in the script, the pthread.h test inside
the block became the very first AC_CHECK_HEADERS call in the script,
triggering that problem.
To fix, use AS_IF instead of plain shell if. AS_IF knows about that issue,
and makes sure the additional code is always executed. To be completely
safe from this issue (and others), we should always be using AS_IF instead
of plain if, but that seems like excessive caution given that this is the
first time we have trouble like this. Plain if-then is more readable than
AS_IF.
This should fix compilation with --disable-thread-safety, and hopefully the
buildfarm failure on forgmouth, related to mingw standard headers, too.
I backpatched the previous fixes to 9.5, but it's starting to look like
these changes are too fiddly to backpatch, so commit this to master only,
and revert all the pthread-related configure changes in 9.5.
2015-07-09 16:38:34 +08:00
AS_IF([test "$enable_thread_safety" = yes -a "$PORTNAME" != "win32"],
[ # then
2015-07-09 05:05:45 +08:00
AX_PTHREAD # set thread flags
# Some platforms use these, so just define them. They can't hurt if they
# are not supported. For example, on Solaris -D_POSIX_PTHREAD_SEMANTICS
# enables 5-arg getpwuid_r, among other things.
PTHREAD_CFLAGS="$PTHREAD_CFLAGS -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
# Check for *_r functions
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
LIBS="$LIBS $PTHREAD_LIBS"
AC_CHECK_HEADER(pthread.h, [], [AC_MSG_ERROR([
pthread.h not found; use --disable-thread-safety to disable thread safety])])
2017-10-11 05:42:16 +08:00
AC_CHECK_FUNCS([strerror_r getpwuid_r gethostbyname_r])
2015-07-09 05:05:45 +08:00
# Do test here with the proper thread flags
PGAC_FUNC_STRERROR_R_INT
CFLAGS="$_CFLAGS"
LIBS="$_LIBS"
Use AS_IF rather than plain shell "if" in pthread-check.
Autoconf generates additional code for the first AC_CHECK_HEADERS call in
the script. If the first call is within an if-block, the additional code is
put inside the if-block too, even though it is needed by subsequent
AC_CHECK_HEADERS checks and should always be executed. When I moved the
pthread-related checks earlier in the script, the pthread.h test inside
the block became the very first AC_CHECK_HEADERS call in the script,
triggering that problem.
To fix, use AS_IF instead of plain shell if. AS_IF knows about that issue,
and makes sure the additional code is always executed. To be completely
safe from this issue (and others), we should always be using AS_IF instead
of plain if, but that seems like excessive caution given that this is the
first time we have trouble like this. Plain if-then is more readable than
AS_IF.
This should fix compilation with --disable-thread-safety, and hopefully the
buildfarm failure on forgmouth, related to mingw standard headers, too.
I backpatched the previous fixes to 9.5, but it's starting to look like
these changes are too fiddly to backpatch, so commit this to master only,
and revert all the pthread-related configure changes in 9.5.
2015-07-09 16:38:34 +08:00
], [ # else
2015-07-09 05:05:45 +08:00
# do not use values from template file
PTHREAD_CFLAGS=
PTHREAD_LIBS=
Use AS_IF rather than plain shell "if" in pthread-check.
Autoconf generates additional code for the first AC_CHECK_HEADERS call in
the script. If the first call is within an if-block, the additional code is
put inside the if-block too, even though it is needed by subsequent
AC_CHECK_HEADERS checks and should always be executed. When I moved the
pthread-related checks earlier in the script, the pthread.h test inside
the block became the very first AC_CHECK_HEADERS call in the script,
triggering that problem.
To fix, use AS_IF instead of plain shell if. AS_IF knows about that issue,
and makes sure the additional code is always executed. To be completely
safe from this issue (and others), we should always be using AS_IF instead
of plain if, but that seems like excessive caution given that this is the
first time we have trouble like this. Plain if-then is more readable than
AS_IF.
This should fix compilation with --disable-thread-safety, and hopefully the
buildfarm failure on forgmouth, related to mingw standard headers, too.
I backpatched the previous fixes to 9.5, but it's starting to look like
these changes are too fiddly to backpatch, so commit this to master only,
and revert all the pthread-related configure changes in 9.5.
2015-07-09 16:38:34 +08:00
]) # fi
2015-07-09 05:05:45 +08:00
AC_SUBST(PTHREAD_CFLAGS)
AC_SUBST(PTHREAD_LIBS)
2000-06-08 00:27:00 +08:00
2002-04-27 03:47:35 +08:00
##
2000-07-13 06:59:15 +08:00
## Libraries
##
2006-11-06 11:44:38 +08:00
## Most libraries are included only if they demonstrably provide a function
## we need, but libm is an exception: always include it, because there are
## too many compilers that play cute optimization games that will break
## probes for standard functions such as pow().
##
2000-07-13 06:59:15 +08:00
2006-11-06 11:44:38 +08:00
AC_CHECK_LIB(m, main)
2006-02-04 08:42:54 +08:00
AC_SEARCH_LIBS(setproctitle, util)
AC_SEARCH_LIBS(dlopen, dl)
2014-07-15 20:18:39 +08:00
AC_SEARCH_LIBS(socket, [socket ws2_32])
2006-02-04 08:42:54 +08:00
AC_SEARCH_LIBS(shl_load, dld)
2002-09-17 12:27:41 +08:00
AC_SEARCH_LIBS(getopt_long, [getopt gnugetopt])
2013-10-10 09:05:02 +08:00
AC_SEARCH_LIBS(shm_open, rt)
AC_SEARCH_LIBS(shm_unlink, rt)
Use clock_gettime(), if available, in instr_time measurements.
The advantage of clock_gettime() is that the API allows the result to
be precise to nanoseconds, not just microseconds as in gettimeofday().
Now that it's routinely possible to do tens of plan node executions
in 1us, we really need more precision than gettimeofday() can offer
for EXPLAIN ANALYZE to accumulate statistics with.
Some research shows that clock_gettime() is available on pretty nearly
every modern Unix-ish platform, and as far as I have been able to test,
it has about the same execution time as gettimeofday(), so there's no
loss in switching over. (By the same token, this doesn't do anything
to fix the fact that we really wish clock readings were faster. But
there's enough win here to justify changing anyway.)
A small side benefit is that on most platforms, we can use CLOCK_MONOTONIC
instead of CLOCK_REALTIME and thereby render EXPLAIN impervious to
concurrent resets of the system clock. (This means that code must not
assume that the contents of struct instr_time have any well-defined
interpretation as timestamps, but really that was true before.)
Some platforms offer nonstandard clock IDs that might be of interest.
This patch knows we should use CLOCK_MONOTONIC_RAW on macOS, because it
provides more precision and is faster to read than their CLOCK_MONOTONIC.
If there turn out to be many more cases where we need special rules, it
might be appropriate to handle the selection of clock ID in configure,
but for the moment that doesn't seem worth the trouble.
Discussion: https://postgr.es/m/31856.1400021891@sss.pgh.pa.us
2017-01-03 02:41:51 +08:00
AC_SEARCH_LIBS(clock_gettime, [rt posix4])
2001-09-11 22:31:23 +08:00
# Solaris:
2001-09-12 20:14:41 +08:00
AC_SEARCH_LIBS(fdatasync, [rt posix4])
2015-07-01 01:20:38 +08:00
# Required for thread_test.c on Solaris
AC_SEARCH_LIBS(sched_yield, rt)
2009-01-15 00:39:58 +08:00
# Required for thread_test.c on Solaris 2.5:
2009-01-15 02:10:21 +08:00
# Other ports use it too (HP-UX) so test unconditionally
AC_SEARCH_LIBS(gethostbyname_r, nsl)
2002-09-06 02:28:46 +08:00
# Cygwin:
2006-02-04 08:42:54 +08:00
AC_SEARCH_LIBS(shmget, cygipc)
2019-11-09 02:44:20 +08:00
# *BSD:
AC_SEARCH_LIBS(backtrace_symbols, execinfo)
2000-07-09 21:14:19 +08:00
2002-04-11 06:47:09 +08:00
if test "$with_readline" = yes; then
PGAC_CHECK_READLINE
if test x"$pgac_cv_check_readline" = x"no"; then
AC_MSG_ERROR([readline library not found
2002-09-11 12:27:48 +08:00
If you have readline already installed, see config.log for details on the
failure. It is possible the compiler isn't looking in the proper directory.
2002-04-11 06:47:09 +08:00
Use --without-readline to disable readline support.])
fi
fi
if test "$with_zlib" = yes; then
AC_CHECK_LIB(z, inflate, [],
[AC_MSG_ERROR([zlib library not found
2002-09-11 12:27:48 +08:00
If you have zlib already installed, see config.log for details on the
failure. It is possible the compiler isn't looking in the proper directory.
2002-04-11 06:47:09 +08:00
Use --without-zlib to disable zlib support.])])
fi
2003-09-14 01:01:09 +08:00
if test "$enable_spinlocks" = yes; then
2003-09-13 00:10:27 +08:00
AC_DEFINE(HAVE_SPINLOCKS, 1, [Define to 1 if you have spinlocks.])
else
AC_MSG_WARN([
*** Not using spinlocks will cause poor performance.])
fi
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-26 05:49:05 +08:00
if test "$enable_atomics" = yes; then
AC_DEFINE(HAVE_ATOMICS, 1, [Define to 1 if you want to use atomics if available.])
else
AC_MSG_WARN([
*** Not using atomic operations will cause poor performance.])
fi
2007-07-10 21:14:22 +08:00
if test "$with_gssapi" = yes ; then
if test "$PORTNAME" != "win32"; then
2007-07-14 19:13:28 +08:00
AC_SEARCH_LIBS(gss_init_sec_context, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [],
2013-11-10 22:20:52 +08:00
[AC_MSG_ERROR([could not find function 'gss_init_sec_context' required for GSSAPI])])
2007-07-10 21:14:22 +08:00
else
LIBS="$LIBS -lgssapi32"
fi
fi
2000-07-09 21:14:19 +08:00
if test "$with_openssl" = yes ; then
dnl Order matters!
2004-10-06 17:35:23 +08:00
if test "$PORTNAME" != "win32"; then
AC_CHECK_LIB(crypto, CRYPTO_new_ex_data, [], [AC_MSG_ERROR([library 'crypto' is required for OpenSSL])])
Support OpenSSL 1.1.0.
Changes needed to build at all:
- Check for SSL_new in configure, now that SSL_library_init is a macro.
- Do not access struct members directly. This includes some new code in
pgcrypto, to use the resource owner mechanism to ensure that we don't
leak OpenSSL handles, now that we can't embed them in other structs
anymore.
- RAND_SSLeay() -> RAND_OpenSSL()
Changes that were needed to silence deprecation warnings, but were not
strictly necessary:
- RAND_pseudo_bytes() -> RAND_bytes().
- SSL_library_init() and OpenSSL_config() -> OPENSSL_init_ssl()
- ASN1_STRING_data() -> ASN1_STRING_get0_data()
- DH_generate_parameters() -> DH_generate_parameters()
- Locking callbacks are not needed with OpenSSL 1.1.0 anymore. (Good
riddance!)
Also change references to SSLEAY_VERSION_NUMBER with OPENSSL_VERSION_NUMBER,
for the sake of consistency. OPENSSL_VERSION_NUMBER has existed since time
immemorial.
Fix SSL test suite to work with OpenSSL 1.1.0. CA certificates must have
the "CA:true" basic constraint extension now, or OpenSSL will refuse them.
Regenerate the test certificates with that. The "openssl" binary, used to
generate the certificates, is also now more picky, and throws an error
if an X509 extension is specified in "req_extensions", but that section
is empty.
Backpatch to all supported branches, per popular demand. In back-branches,
we still support OpenSSL 0.9.7 and above. OpenSSL 0.9.6 should still work
too, but I didn't test it. In master, we only support 0.9.8 and above.
Patch by Andreas Karlsson, with additional changes by me.
Discussion: <20160627151604.GD1051@msg.df7cb.de>
2016-09-15 17:36:21 +08:00
AC_CHECK_LIB(ssl, SSL_new, [], [AC_MSG_ERROR([library 'ssl' is required for OpenSSL])])
2004-10-06 17:35:23 +08:00
else
2017-11-09 06:47:14 +08:00
AC_SEARCH_LIBS(CRYPTO_new_ex_data, [eay32 crypto], [], [AC_MSG_ERROR([library 'eay32' or 'crypto' is required for OpenSSL])])
AC_SEARCH_LIBS(SSL_new, [ssleay32 ssl], [], [AC_MSG_ERROR([library 'ssleay32' or 'ssl' is required for OpenSSL])])
2004-10-06 17:35:23 +08:00
fi
Fix handling of OpenSSL's SSL_clear_options
This function is supported down to OpenSSL 0.9.8, which is the oldest
version supported since 593d4e4 (from Postgres 10 onwards), and is used
since e3bdb2d (from 11 onwards). It is defined as a macro from OpenSSL
0.9.8 to 1.0.2, and as a function in 1.1.0 and newer versions. However,
the configure check present is only adapted for functions. So, even if
the code would be able to compile, configure fails to detect the macro,
causing it to be ignored when compiling the code with OpenSSL from 0.9.8
to 1.0.2.
The code needs a configure check as per a364dfa, which has fixed a
compilation issue with a past version of LibreSSL in NetBSD 5.1. On
HEAD, just remove the configure check as the last release of NetBSD 5 is
from 2014 (and we have no more buildfarm members for it). In 11 and 12,
improve the configure logic so as both macros and functions are
correctly detected. This makes NetBSD 5 still work on already-released
branches, but not for 13 onwards.
The patch for HEAD is from me, and Daniel has written the version to use
for the back-branches.
Author: Michael Paquier, Daniel Gustaffson
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz
Discussion: https://postgr.es/m/98F7F99E-1129-41D8-B86B-FE3B1E286881@yesql.se
Backpatch-through: 11
2019-12-06 14:13:55 +08:00
# Function introduced in OpenSSL 1.0.2.
AC_CHECK_FUNCS([X509_get_signature_nid])
2016-09-16 03:29:39 +08:00
# Functions introduced in OpenSSL 1.1.0. We used to check for
# OPENSSL_VERSION_NUMBER, but that didn't work with 1.1.0, because LibreSSL
# defines OPENSSL_VERSION_NUMBER to claim version 2.0.0, even though it
# doesn't have these OpenSSL 1.1.0 functions. So check for individual
# functions.
2019-06-27 07:25:26 +08:00
AC_CHECK_FUNCS([OPENSSL_init_ssl BIO_get_data BIO_meth_new ASN1_STRING_get0_data])
2016-09-16 03:29:39 +08:00
# OpenSSL versions before 1.1.0 required setting callback functions, for
# thread-safety. In 1.1.0, it's no longer required, and CRYPTO_lock()
# function was removed.
AC_CHECK_FUNCS([CRYPTO_lock])
2000-07-09 21:14:19 +08:00
fi
1997-02-04 16:53:45 +08:00
2001-09-06 11:23:38 +08:00
if test "$with_pam" = yes ; then
2002-12-29 11:56:35 +08:00
AC_CHECK_LIB(pam, pam_start, [], [AC_MSG_ERROR([library 'pam' is required for PAM])])
2001-09-06 11:23:38 +08:00
fi
2006-12-22 00:05:16 +08:00
if test "$with_libxml" = yes ; then
2007-01-08 05:10:41 +08:00
AC_CHECK_LIB(xml2, xmlSaveToBuffer, [], [AC_MSG_ERROR([library 'xml2' (version >= 2.6.23) is required for XML support])])
2006-12-22 00:05:16 +08:00
fi
2007-04-15 20:48:24 +08:00
if test "$with_libxslt" = yes ; then
2008-04-29 06:47:03 +08:00
AC_CHECK_LIB(xslt, xsltCleanupGlobals, [], [AC_MSG_ERROR([library 'xslt' is required for XSLT support])])
2007-04-15 20:48:24 +08:00
fi
2015-07-09 05:05:45 +08:00
# Note: We can test for libldap_r only after we know PTHREAD_LIBS
if test "$with_ldap" = yes ; then
_LIBS="$LIBS"
if test "$PORTNAME" != "win32"; then
AC_CHECK_LIB(ldap, ldap_bind, [],
[AC_MSG_ERROR([library 'ldap' is required for LDAP])],
[$EXTRA_LDAP_LIBS])
LDAP_LIBS_BE="-lldap $EXTRA_LDAP_LIBS"
if test "$enable_thread_safety" = yes; then
# on some platforms ldap_r fails to link without PTHREAD_LIBS
AC_CHECK_LIB(ldap_r, ldap_simple_bind, [],
[AC_MSG_ERROR([library 'ldap_r' is required for LDAP])],
[$PTHREAD_CFLAGS $PTHREAD_LIBS $EXTRA_LDAP_LIBS])
LDAP_LIBS_FE="-lldap_r $EXTRA_LDAP_LIBS"
else
LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS"
fi
2018-01-03 23:00:08 +08:00
AC_CHECK_FUNCS([ldap_initialize])
2015-07-09 05:05:45 +08:00
else
AC_CHECK_LIB(wldap32, ldap_bind, [], [AC_MSG_ERROR([library 'wldap32' is required for LDAP])])
LDAP_LIBS_FE="-lwldap32"
LDAP_LIBS_BE="-lwldap32"
fi
LIBS="$_LIBS"
fi
AC_SUBST(LDAP_LIBS_FE)
AC_SUBST(LDAP_LIBS_BE)
2011-01-24 09:44:48 +08:00
# for contrib/sepgsql
if test "$with_selinux" = yes; then
2013-03-29 03:38:35 +08:00
AC_CHECK_LIB(selinux, security_compute_create_name, [],
[AC_MSG_ERROR([library 'libselinux', version 2.1.10 or newer, is required for SELinux support])])
2011-01-24 09:44:48 +08:00
fi
2007-11-13 08:13:19 +08:00
# for contrib/uuid-ossp
2014-05-28 07:42:08 +08:00
if test "$with_uuid" = bsd ; then
# On BSD, the UUID functions are in libc
AC_CHECK_FUNC(uuid_to_string,
[UUID_LIBS=""],
[AC_MSG_ERROR([BSD UUID functions are not present])])
elif test "$with_uuid" = e2fs ; then
Refer to OS X as "macOS", except for the port name which is still "darwin".
We weren't terribly consistent about whether to call Apple's OS "OS X"
or "Mac OS X", and the former is probably confusing to people who aren't
Apple users. Now that Apple has rebranded it "macOS", follow their lead
to establish a consistent naming pattern. Also, avoid the use of the
ancient project name "Darwin", except as the port code name which does not
seem desirable to change. (In short, this patch touches documentation and
comments, but no actual code.)
I didn't touch contrib/start-scripts/osx/, either. I suspect those are
obsolete and due for a rewrite, anyway.
I dithered about whether to apply this edit to old release notes, but
those were responsible for quite a lot of the inconsistencies, so I ended
up changing them too. Anyway, Apple's being ahistorical about this,
so why shouldn't we be?
2016-09-26 03:40:57 +08:00
# On macOS, the UUID functions are in libc
2014-05-28 07:42:08 +08:00
AC_CHECK_FUNC(uuid_generate,
[UUID_LIBS=""],
[AC_CHECK_LIB(uuid, uuid_generate,
[UUID_LIBS="-luuid"],
[AC_MSG_ERROR([library 'uuid' is required for E2FS UUID])])])
elif test "$with_uuid" = ossp ; then
2007-11-13 08:13:19 +08:00
AC_CHECK_LIB(ossp-uuid, uuid_export,
2014-05-28 07:42:08 +08:00
[UUID_LIBS="-lossp-uuid"],
2007-11-13 08:13:19 +08:00
[AC_CHECK_LIB(uuid, uuid_export,
2014-05-28 07:42:08 +08:00
[UUID_LIBS="-luuid"],
[AC_MSG_ERROR([library 'ossp-uuid' or 'uuid' is required for OSSP UUID])])])
2007-11-13 08:13:19 +08:00
fi
2014-05-28 07:42:08 +08:00
AC_SUBST(UUID_LIBS)
2007-11-13 08:13:19 +08:00
2002-03-30 01:32:55 +08:00
2000-07-13 06:59:15 +08:00
##
## Header files
##
2002-07-28 04:10:05 +08:00
2018-03-21 19:43:29 +08:00
AC_HEADER_STDBOOL
2018-10-09 12:04:27 +08:00
AC_CHECK_HEADERS(m4_normalize([
atomic.h
2018-11-08 05:41:42 +08:00
copyfile.h
2019-11-09 02:44:20 +08:00
execinfo.h
2018-10-09 12:04:27 +08:00
getopt.h
ifaddrs.h
langinfo.h
mbarrier.h
poll.h
sys/epoll.h
Add kqueue(2) support to the WaitEventSet API.
Use kevent(2) to wait for events on the BSD family of operating
systems and macOS. This is similar to the epoll(2) support added
for Linux by commit 98a64d0bd.
Author: Thomas Munro
Reviewed-by: Andres Freund, Marko Tiikkaja, Tom Lane
Tested-by: Mateusz Guzik, Matteo Beccati, Keith Fiske, Heikki Linnakangas, Michael Paquier, Peter Eisentraut, Rui DeSousa, Tom Lane, Mark Wong
Discussion: https://postgr.es/m/CAEepm%3D37oF84-iXDTQ9MrGjENwVGds%2B5zTr38ca73kWR7ez_tA%40mail.gmail.com
2020-02-05 12:35:57 +08:00
sys/event.h
2018-10-09 12:04:27 +08:00
sys/ipc.h
sys/prctl.h
sys/procctl.h
sys/pstat.h
sys/resource.h
sys/select.h
sys/sem.h
sys/shm.h
sys/sockio.h
sys/tas.h
sys/un.h
termios.h
ucred.h
wctype.h
]))
2009-10-01 09:58:58 +08:00
2013-07-25 23:39:08 +08:00
# On BSD, test for net/if.h will fail unless sys/socket.h
2009-10-01 09:58:58 +08:00
# is included first.
AC_CHECK_HEADERS(net/if.h, [], [],
[AC_INCLUDES_DEFAULT
#include <sys/socket.h>
])
2000-10-24 22:55:28 +08:00
2013-07-25 23:39:08 +08:00
# On OpenBSD, test for sys/ucred.h will fail unless sys/param.h
# is included first.
AC_CHECK_HEADERS(sys/ucred.h, [], [],
[AC_INCLUDES_DEFAULT
#include <sys/param.h>
])
# At least on IRIX, test for netinet/tcp.h will fail unless
2002-03-30 01:32:55 +08:00
# netinet/in.h is included first.
2002-12-29 11:56:35 +08:00
AC_CHECK_HEADERS(netinet/tcp.h, [], [],
2002-03-30 08:59:52 +08:00
[AC_INCLUDES_DEFAULT
2000-10-24 22:55:28 +08:00
#include <netinet/in.h>
2002-03-30 01:32:55 +08:00
])
2000-11-04 02:43:52 +08:00
2004-11-30 14:13:04 +08:00
if expr x"$pgac_cv_check_readline" : 'x-lreadline' >/dev/null ; then
2002-12-29 11:56:35 +08:00
AC_CHECK_HEADERS(readline/readline.h, [],
2004-12-03 05:41:12 +08:00
[AC_CHECK_HEADERS(readline.h, [],
[AC_MSG_ERROR([readline header not found
2002-09-11 12:27:48 +08:00
If you have readline already installed, see config.log for details on the
failure. It is possible the compiler isn't looking in the proper directory.
2004-11-30 14:13:04 +08:00
Use --without-readline to disable readline support.])])])
2002-12-29 11:56:35 +08:00
AC_CHECK_HEADERS(readline/history.h, [],
2004-12-03 05:41:12 +08:00
[AC_CHECK_HEADERS(history.h, [],
[AC_MSG_ERROR([history header not found
2002-09-11 12:27:48 +08:00
If you have readline already installed, see config.log for details on the
failure. It is possible the compiler isn't looking in the proper directory.
2004-11-30 14:13:04 +08:00
Use --without-readline to disable readline support.])])])
fi
if expr x"$pgac_cv_check_readline" : 'x-ledit' >/dev/null ; then
2004-12-03 05:41:12 +08:00
# Some installations of libedit usurp /usr/include/readline/, which seems
# bad practice, since in combined installations readline will have its headers
# there. We might have to resort to AC_EGREP checks to make sure we found
# the proper header...
2004-11-30 14:13:04 +08:00
AC_CHECK_HEADERS(editline/readline.h, [],
2004-12-03 05:41:12 +08:00
[AC_CHECK_HEADERS(readline.h, [],
[AC_CHECK_HEADERS(readline/readline.h, [],
[AC_MSG_ERROR([readline header not found
2004-11-30 14:13:04 +08:00
If you have libedit already installed, see config.log for details on the
failure. It is possible the compiler isn't looking in the proper directory.
2004-12-03 05:41:12 +08:00
Use --without-readline to disable libedit support.])])])])
2006-10-05 08:07:45 +08:00
# Note: in a libedit installation, history.h is sometimes a dummy, and may
# not be there at all. Hence, don't complain if not found. We must check
# though, since in yet other versions it is an independent header.
AC_CHECK_HEADERS(editline/history.h, [],
[AC_CHECK_HEADERS(history.h, [],
[AC_CHECK_HEADERS(readline/history.h)])])
2002-04-11 06:47:09 +08:00
fi
if test "$with_zlib" = yes; then
AC_CHECK_HEADER(zlib.h, [], [AC_MSG_ERROR([zlib header not found
2003-01-11 12:58:44 +08:00
If you have zlib already installed, see config.log for details on the
2002-09-11 12:27:48 +08:00
failure. It is possible the compiler isn't looking in the proper directory.
2002-04-11 06:47:09 +08:00
Use --without-zlib to disable zlib support.])])
fi
2000-06-20 00:58:48 +08:00
2007-07-10 21:14:22 +08:00
if test "$with_gssapi" = yes ; then
2007-07-12 22:36:52 +08:00
AC_CHECK_HEADERS(gssapi/gssapi.h, [],
[AC_CHECK_HEADERS(gssapi.h, [], [AC_MSG_ERROR([gssapi.h header file is required for GSSAPI])])])
2007-07-10 21:14:22 +08:00
fi
2000-07-09 21:14:19 +08:00
if test "$with_openssl" = yes ; then
2002-12-29 11:56:35 +08:00
AC_CHECK_HEADER(openssl/ssl.h, [], [AC_MSG_ERROR([header file <openssl/ssl.h> is required for OpenSSL])])
AC_CHECK_HEADER(openssl/err.h, [], [AC_MSG_ERROR([header file <openssl/err.h> is required for OpenSSL])])
2000-07-09 21:14:19 +08:00
fi
2001-09-06 11:23:38 +08:00
if test "$with_pam" = yes ; then
2003-02-14 22:05:00 +08:00
AC_CHECK_HEADERS(security/pam_appl.h, [],
[AC_CHECK_HEADERS(pam/pam_appl.h, [],
[AC_MSG_ERROR([header file <security/pam_appl.h> or <pam/pam_appl.h> is required for PAM.])])])
2001-09-06 11:23:38 +08:00
fi
2016-04-09 01:51:54 +08:00
if test "$with_bsd_auth" = yes ; then
AC_CHECK_HEADER(bsd_auth.h, [], [AC_MSG_ERROR([header file <bsd_auth.h> is required for BSD Authentication support])])
fi
2015-11-17 19:46:17 +08:00
if test "$with_systemd" = yes ; then
AC_CHECK_HEADER(systemd/sd-daemon.h, [], [AC_MSG_ERROR([header file <systemd/sd-daemon.h> is required for systemd support])])
fi
2006-12-22 00:05:16 +08:00
if test "$with_libxml" = yes ; then
AC_CHECK_HEADER(libxml/parser.h, [], [AC_MSG_ERROR([header file <libxml/parser.h> is required for XML support])])
fi
2007-04-15 20:48:24 +08:00
if test "$with_libxslt" = yes ; then
AC_CHECK_HEADER(libxslt/xslt.h, [], [AC_MSG_ERROR([header file <libxslt/xslt.h> is required for XSLT support])])
fi
2006-03-07 01:41:44 +08:00
if test "$with_ldap" = yes ; then
if test "$PORTNAME" != "win32"; then
AC_CHECK_HEADERS(ldap.h, [],
[AC_MSG_ERROR([header file <ldap.h> is required for LDAP])])
2014-07-22 23:01:03 +08:00
PGAC_LDAP_SAFE
2006-03-07 01:41:44 +08:00
else
AC_CHECK_HEADERS(winldap.h, [],
[AC_MSG_ERROR([header file <winldap.h> is required for LDAP])],
[AC_INCLUDES_DEFAULT
#include <windows.h>
])
fi
fi
2005-05-15 08:26:19 +08:00
if test "$with_bonjour" = yes ; then
2009-09-09 00:08:26 +08:00
AC_CHECK_HEADER(dns_sd.h, [], [AC_MSG_ERROR([header file <dns_sd.h> is required for Bonjour])])
2017-11-10 00:00:36 +08:00
dnl At some point we might add something like
dnl AC_SEARCH_LIBS(DNSServiceRegister, dns_sd)
dnl but right now, what that would mainly accomplish is to encourage
dnl people to try to use the avahi implementation, which does not work.
dnl If you want to use Apple's own Bonjour code on another platform,
dnl just add -ldns_sd to LIBS manually.
2003-06-11 14:56:07 +08:00
fi
2007-10-24 05:38:16 +08:00
# for contrib/uuid-ossp
2014-05-28 07:42:08 +08:00
if test "$with_uuid" = bsd ; then
AC_CHECK_HEADERS(uuid.h,
[AC_EGREP_HEADER([uuid_to_string], uuid.h, [],
[AC_MSG_ERROR([header file <uuid.h> does not match BSD UUID library])])],
[AC_MSG_ERROR([header file <uuid.h> is required for BSD UUID])])
elif test "$with_uuid" = e2fs ; then
AC_CHECK_HEADERS(uuid/uuid.h,
[AC_EGREP_HEADER([uuid_generate], uuid/uuid.h, [],
[AC_MSG_ERROR([header file <uuid/uuid.h> does not match E2FS UUID library])])],
[AC_CHECK_HEADERS(uuid.h,
[AC_EGREP_HEADER([uuid_generate], uuid.h, [],
[AC_MSG_ERROR([header file <uuid.h> does not match E2FS UUID library])])],
[AC_MSG_ERROR([header file <uuid/uuid.h> or <uuid.h> is required for E2FS UUID])])])
elif test "$with_uuid" = ossp ; then
AC_CHECK_HEADERS(ossp/uuid.h,
[AC_EGREP_HEADER([uuid_export], ossp/uuid.h, [],
[AC_MSG_ERROR([header file <ossp/uuid.h> does not match OSSP UUID library])])],
[AC_CHECK_HEADERS(uuid.h,
[AC_EGREP_HEADER([uuid_export], uuid.h, [],
[AC_MSG_ERROR([header file <uuid.h> does not match OSSP UUID library])])],
[AC_MSG_ERROR([header file <ossp/uuid.h> or <uuid.h> is required for OSSP UUID])])])
2007-10-24 05:38:16 +08:00
fi
2011-12-11 04:35:41 +08:00
if test "$PORTNAME" = "win32" ; then
AC_CHECK_HEADERS(crtdefs.h)
fi
1997-02-04 16:53:45 +08:00
2000-07-13 06:59:15 +08:00
##
## Types, structures, compiler characteristics
##
2002-07-28 04:10:05 +08:00
2002-03-30 01:32:55 +08:00
m4_defun([AC_PROG_CC_STDC], []) dnl We don't want that.
2007-04-06 12:21:44 +08:00
AC_C_BIGENDIAN
2015-08-06 00:19:52 +08:00
AC_C_INLINE
2014-11-23 22:34:03 +08:00
PGAC_PRINTF_ARCHETYPE
2003-04-25 05:16:45 +08:00
PGAC_C_FUNCNAME_SUPPORT
2012-10-01 02:38:31 +08:00
PGAC_C_STATIC_ASSERT
2017-03-10 04:18:59 +08:00
PGAC_C_TYPEOF
2012-10-01 02:38:31 +08:00
PGAC_C_TYPES_COMPATIBLE
Improve handling of ereport(ERROR) and elog(ERROR).
In commit 71450d7fd6c7cf7b3e38ac56e363bff6a681973c, we added code to inform
suitably-intelligent compilers that ereport() doesn't return if the elevel
is ERROR or higher. This patch extends that to elog(), and also fixes a
double-evaluation hazard that the previous commit created in ereport(),
as well as reducing the emitted code size.
The elog() improvement requires the compiler to support __VA_ARGS__, which
should be available in just about anything nowadays since it's required by
C99. But our minimum language baseline is still C89, so add a configure
test for that.
The previous commit assumed that ereport's elevel could be evaluated twice,
which isn't terribly safe --- there are already counterexamples in xlog.c.
On compilers that have __builtin_constant_p, we can use that to protect the
second test, since there's no possible optimization gain if the compiler
doesn't know the value of elevel. Otherwise, use a local variable inside
the macros to prevent double evaluation. The local-variable solution is
inferior because (a) it leads to useless code being emitted when elevel
isn't constant, and (b) it increases the optimization level needed for the
compiler to recognize that subsequent code is unreachable. But it seems
better than not teaching non-gcc compilers about unreachability at all.
Lastly, if the compiler has __builtin_unreachable(), we can use that
instead of abort(), resulting in a noticeable code savings since no
function call is actually emitted. However, it seems wise to do this only
in non-assert builds. In an assert build, continue to use abort(), so that
the behavior will be predictable and debuggable if the "impossible"
happens.
These changes involve making the ereport and elog macros emit do-while
statement blocks not just expressions, which forces small changes in
a few call sites.
Andres Freund, Tom Lane, Heikki Linnakangas
2013-01-14 07:39:20 +08:00
PGAC_C_BUILTIN_CONSTANT_P
PGAC_C_BUILTIN_UNREACHABLE
2017-03-21 01:35:21 +08:00
PGAC_C_COMPUTED_GOTO
2003-05-23 00:39:30 +08:00
PGAC_STRUCT_TIMEZONE
2000-07-13 06:59:15 +08:00
PGAC_UNION_SEMUN
2000-09-27 23:17:57 +08:00
PGAC_STRUCT_SOCKADDR_UN
2003-06-12 15:36:51 +08:00
PGAC_STRUCT_SOCKADDR_STORAGE
2003-07-24 07:30:41 +08:00
PGAC_STRUCT_SOCKADDR_STORAGE_MEMBERS
2003-04-02 08:49:28 +08:00
PGAC_STRUCT_ADDRINFO
1997-02-06 13:30:50 +08:00
2011-02-09 05:04:18 +08:00
PGAC_TYPE_LOCALE_T
2017-10-13 06:25:38 +08:00
# MSVC doesn't cope well with defining restrict to __restrict, the
# spelling it understands, because it conflicts with
# __declspec(restrict). Therefore we define pg_restrict to the
# appropriate definition, which presumably won't conflict.
2017-10-14 02:54:59 +08:00
#
# Allow platforms with buggy compilers to force restrict to not be
# used by setting $FORCE_DISABLE_RESTRICT=yes in the relevant
# template.
2017-10-13 06:25:38 +08:00
AC_C_RESTRICT
2017-10-14 02:54:59 +08:00
if test "$ac_cv_c_restrict" = "no" -o "x$FORCE_DISABLE_RESTRICT" = "xyes"; then
2017-10-13 06:25:38 +08:00
pg_restrict=""
else
pg_restrict="$ac_cv_c_restrict"
fi
AC_DEFINE_UNQUOTED([pg_restrict], [$pg_restrict],
[Define to keyword to use for C99 restrict support, or to nothing if not
supported])
Replace use of credential control messages with getsockopt(LOCAL_PEERCRED).
It turns out the reason we hadn't found out about the portability issues
with our credential-control-message code is that almost no modern platforms
use that code at all; the ones that used to need it now offer getpeereid(),
which we choose first. The last holdout was NetBSD, and they added
getpeereid() as of 5.0. So far as I can tell, the only live platform on
which that code was being exercised was Debian/kFreeBSD, ie, FreeBSD kernel
with Linux userland --- since glibc doesn't provide getpeereid(), we fell
back to the control message code. However, the FreeBSD kernel provides a
LOCAL_PEERCRED socket parameter that's functionally equivalent to Linux's
SO_PEERCRED. That is both much simpler to use than control messages, and
superior because it doesn't require receiving a message from the other end
at just the right time.
Therefore, add code to use LOCAL_PEERCRED when necessary, and rip out all
the credential-control-message code in the backend. (libpq still has such
code so that it can still talk to pre-9.1 servers ... but eventually we can
get rid of it there too.) Clean up related autoconf probes, too.
This means that libpq's requirepeer parameter now works on exactly the same
platforms where the backend supports peer authentication, so adjust the
documentation accordingly.
2011-06-01 04:10:46 +08:00
AC_CHECK_TYPES([struct cmsgcred], [], [],
[#include <sys/socket.h>
2013-07-25 23:39:08 +08:00
#include <sys/param.h>
Replace use of credential control messages with getsockopt(LOCAL_PEERCRED).
It turns out the reason we hadn't found out about the portability issues
with our credential-control-message code is that almost no modern platforms
use that code at all; the ones that used to need it now offer getpeereid(),
which we choose first. The last holdout was NetBSD, and they added
getpeereid() as of 5.0. So far as I can tell, the only live platform on
which that code was being exercised was Debian/kFreeBSD, ie, FreeBSD kernel
with Linux userland --- since glibc doesn't provide getpeereid(), we fell
back to the control message code. However, the FreeBSD kernel provides a
LOCAL_PEERCRED socket parameter that's functionally equivalent to Linux's
SO_PEERCRED. That is both much simpler to use than control messages, and
superior because it doesn't require receiving a message from the other end
at just the right time.
Therefore, add code to use LOCAL_PEERCRED when necessary, and rip out all
the credential-control-message code in the backend. (libpq still has such
code so that it can still talk to pre-9.1 servers ... but eventually we can
get rid of it there too.) Clean up related autoconf probes, too.
This means that libpq's requirepeer parameter now works on exactly the same
platforms where the backend supports peer authentication, so adjust the
documentation accordingly.
2011-06-01 04:10:46 +08:00
#ifdef HAVE_SYS_UCRED_H
#include <sys/ucred.h>
#endif])
2002-03-30 01:32:55 +08:00
2003-08-08 05:11:58 +08:00
AC_CHECK_TYPES([struct option], [], [],
[#ifdef HAVE_GETOPT_H
2003-08-08 05:38:55 +08:00
#include <getopt.h>
2003-08-08 05:11:58 +08:00
#endif])
2002-04-11 06:47:09 +08:00
if test "$with_zlib" = yes; then
# Check that <zlib.h> defines z_streamp (versions before about 1.0.4
# did not). While we could work around the lack of z_streamp, it
# seems unwise to encourage people to use such old zlib versions...
AC_CHECK_TYPE(z_streamp, [], [AC_MSG_ERROR([zlib version is too old
Use --without-zlib to disable zlib support.])],
[#include <zlib.h>])
fi
2012-01-02 11:39:59 +08:00
case $host_cpu in
Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT.
Test for the compiler builtins __builtin_clz, __builtin_ctz, and
__builtin_popcount, and make use of these in preference to
handwritten C code if they're available. Create src/port
infrastructure for "leftmost one", "rightmost one", and "popcount"
so as to centralize these decisions.
On x86_64, __builtin_popcount generally won't make use of the POPCNT
opcode because that's not universally supported yet. Provide code
that checks CPUID and then calls POPCNT via asm() if available.
This requires indirecting through a function pointer, which is
an annoying amount of overhead for a one-instruction operation,
but it's probably not worth working harder than this for our
current use-cases.
I'm not sure we've found all the existing places that could profit
from this new infrastructure; but we at least touched all the
ones that used copied-and-pasted versions of the bitmapset.c code,
and got rid of multiple copies of the associated constant arrays.
While at it, replace c-compiler.m4's one-per-builtin-function
macros with a single one that can handle all the cases we need
to worry about so far. Also, because I'm paranoid, make those
checks into AC_LINK checks rather than just AC_COMPILE; the
former coding failed to verify that libgcc has support for the
builtin, in cases where it's not inline code.
David Rowley, Thomas Munro, Alvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/CAKJS1f9WTAGG1tPeJnD18hiQW5gAk59fQ6WK-vfdAKEHyRg2RA@mail.gmail.com
2019-02-16 12:22:27 +08:00
x86_64)
# On x86_64, check if we can compile a popcntq instruction
AC_CACHE_CHECK([whether assembler supports x86_64 popcntq],
[pgac_cv_have_x86_64_popcntq],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],
[long long x = 1; long long r;
__asm__ __volatile__ (" popcntq %1,%0\n" : "=q"(r) : "rm"(x));])],
[pgac_cv_have_x86_64_popcntq=yes],
[pgac_cv_have_x86_64_popcntq=no])])
if test x"$pgac_cv_have_x86_64_popcntq" = xyes ; then
AC_DEFINE(HAVE_X86_64_POPCNTQ, 1, [Define to 1 if the assembler supports X86_64's POPCNTQ instruction.])
fi
;;
2012-01-02 11:39:59 +08:00
ppc*|powerpc*)
Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT.
Test for the compiler builtins __builtin_clz, __builtin_ctz, and
__builtin_popcount, and make use of these in preference to
handwritten C code if they're available. Create src/port
infrastructure for "leftmost one", "rightmost one", and "popcount"
so as to centralize these decisions.
On x86_64, __builtin_popcount generally won't make use of the POPCNT
opcode because that's not universally supported yet. Provide code
that checks CPUID and then calls POPCNT via asm() if available.
This requires indirecting through a function pointer, which is
an annoying amount of overhead for a one-instruction operation,
but it's probably not worth working harder than this for our
current use-cases.
I'm not sure we've found all the existing places that could profit
from this new infrastructure; but we at least touched all the
ones that used copied-and-pasted versions of the bitmapset.c code,
and got rid of multiple copies of the associated constant arrays.
While at it, replace c-compiler.m4's one-per-builtin-function
macros with a single one that can handle all the cases we need
to worry about so far. Also, because I'm paranoid, make those
checks into AC_LINK checks rather than just AC_COMPILE; the
former coding failed to verify that libgcc has support for the
builtin, in cases where it's not inline code.
David Rowley, Thomas Munro, Alvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/CAKJS1f9WTAGG1tPeJnD18hiQW5gAk59fQ6WK-vfdAKEHyRg2RA@mail.gmail.com
2019-02-16 12:22:27 +08:00
# On PPC, check if assembler supports LWARX instruction's mutex hint bit
AC_CACHE_CHECK([whether assembler supports lwarx hint bit],
[pgac_cv_have_ppc_mutex_hint],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],
2012-01-02 11:39:59 +08:00
[int a = 0; int *p = &a; int r;
2015-07-03 00:21:23 +08:00
__asm__ __volatile__ (" lwarx %0,0,%1,1\n" : "=&r"(r) : "r"(p));])],
2012-01-02 11:39:59 +08:00
[pgac_cv_have_ppc_mutex_hint=yes],
Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT.
Test for the compiler builtins __builtin_clz, __builtin_ctz, and
__builtin_popcount, and make use of these in preference to
handwritten C code if they're available. Create src/port
infrastructure for "leftmost one", "rightmost one", and "popcount"
so as to centralize these decisions.
On x86_64, __builtin_popcount generally won't make use of the POPCNT
opcode because that's not universally supported yet. Provide code
that checks CPUID and then calls POPCNT via asm() if available.
This requires indirecting through a function pointer, which is
an annoying amount of overhead for a one-instruction operation,
but it's probably not worth working harder than this for our
current use-cases.
I'm not sure we've found all the existing places that could profit
from this new infrastructure; but we at least touched all the
ones that used copied-and-pasted versions of the bitmapset.c code,
and got rid of multiple copies of the associated constant arrays.
While at it, replace c-compiler.m4's one-per-builtin-function
macros with a single one that can handle all the cases we need
to worry about so far. Also, because I'm paranoid, make those
checks into AC_LINK checks rather than just AC_COMPILE; the
former coding failed to verify that libgcc has support for the
builtin, in cases where it's not inline code.
David Rowley, Thomas Munro, Alvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/CAKJS1f9WTAGG1tPeJnD18hiQW5gAk59fQ6WK-vfdAKEHyRg2RA@mail.gmail.com
2019-02-16 12:22:27 +08:00
[pgac_cv_have_ppc_mutex_hint=no])])
2012-01-02 11:39:59 +08:00
if test x"$pgac_cv_have_ppc_mutex_hint" = xyes ; then
AC_DEFINE(HAVE_PPC_LWARX_MUTEX_HINT, 1, [Define to 1 if the assembler supports PPC's LWARX mutex hint bit.])
fi
2019-10-19 11:20:52 +08:00
# Check if compiler accepts "i"(x) when __builtin_constant_p(x).
AC_CACHE_CHECK([whether __builtin_constant_p(x) implies "i"(x) acceptance],
[pgac_cv_have_i_constraint__builtin_constant_p],
[AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
[static inline int
addi(int ra, int si)
{
int res = 0;
if (__builtin_constant_p(si))
__asm__ __volatile__(
" addi %0,%1,%2\n" : "=r"(res) : "b"(ra), "i"(si));
return res;
}
int test_adds(int x) { return addi(3, x) + addi(x, 5); }], [])],
[pgac_cv_have_i_constraint__builtin_constant_p=yes],
[pgac_cv_have_i_constraint__builtin_constant_p=no])])
if test x"$pgac_cv_have_i_constraint__builtin_constant_p" = xyes ; then
AC_DEFINE(HAVE_I_CONSTRAINT__BUILTIN_CONSTANT_P, 1,
[Define to 1 if __builtin_constant_p(x) implies "i"(x) acceptance.])
fi
2012-01-02 11:39:59 +08:00
;;
esac
2010-01-17 03:50:26 +08:00
# Check largefile support. You might think this is a system service not a
# compiler characteristic, but you'd be wrong. We must check this before
# probing existence of related functions such as fseeko, since the largefile
# defines can affect what is generated for that.
2011-12-11 04:35:41 +08:00
if test "$PORTNAME" != "win32"; then
AC_SYS_LARGEFILE
2014-02-23 09:42:39 +08:00
dnl Autoconf 2.69's AC_SYS_LARGEFILE believes it's a good idea to #define
Refer to OS X as "macOS", except for the port name which is still "darwin".
We weren't terribly consistent about whether to call Apple's OS "OS X"
or "Mac OS X", and the former is probably confusing to people who aren't
Apple users. Now that Apple has rebranded it "macOS", follow their lead
to establish a consistent naming pattern. Also, avoid the use of the
ancient project name "Darwin", except as the port code name which does not
seem desirable to change. (In short, this patch touches documentation and
comments, but no actual code.)
I didn't touch contrib/start-scripts/osx/, either. I suspect those are
obsolete and due for a rewrite, anyway.
I dithered about whether to apply this edit to old release notes, but
those were responsible for quite a lot of the inconsistencies, so I ended
up changing them too. Anyway, Apple's being ahistorical about this,
so why shouldn't we be?
2016-09-26 03:40:57 +08:00
dnl _DARWIN_USE_64_BIT_INODE, but it isn't: on macOS 10.5 that activates a
dnl bug that causes readdir() to sometimes return EINVAL. On later macOS
2014-02-23 09:42:39 +08:00
dnl versions where the feature actually works, it's on by default anyway.
2013-12-30 01:57:45 +08:00
AH_VERBATIM([_DARWIN_USE_64_BIT_INODE],[])
2011-12-11 04:35:41 +08:00
fi
2010-01-17 03:50:26 +08:00
2019-02-09 22:55:17 +08:00
dnl Check for largefile support (must be after AC_SYS_LARGEFILE)
2010-01-17 03:50:26 +08:00
AC_CHECK_SIZEOF([off_t])
# If we don't have largefile support, can't handle segsize >= 2GB.
2010-11-24 04:27:50 +08:00
if test "$ac_cv_sizeof_off_t" -lt 8 -a "$segsize" != "1"; then
AC_MSG_ERROR([Large file support is not enabled. Segment size cannot be larger than 1GB.])
2010-01-17 03:50:26 +08:00
fi
2018-03-21 19:43:29 +08:00
AC_CHECK_SIZEOF([bool], [],
[#ifdef HAVE_STDBOOL_H
#include <stdbool.h>
#endif])
Fix ecpglib.h to declare bool consistently with c.h.
This completes the task begun in commit 1408d5d86, to synchronize
ECPG's exported definitions with the definition of bool used by
c.h (and, therefore, the one actually in use in the ECPG library).
On practically all modern platforms, ecpglib.h will now just
include <stdbool.h>, which should surprise nobody anymore.
That removes a header-inclusion-order hazard for ECPG clients,
who previously might get build failures or unexpected behavior
depending on whether they'd included <stdbool.h> themselves,
and if so, whether before or after ecpglib.h.
On platforms where sizeof(_Bool) is not 1 (only old PPC-based
Mac systems, as far as I know), things are still messy, as
inclusion of <stdbool.h> could still break ECPG client code.
There doesn't seem to be any clean fix for that, and given the
probably-negligible population of users who would care anymore,
it's not clear we should go far out of our way to cope with it.
This change at least fixes some header-inclusion-order hazards
for our own code, since c.h and ecpglib.h previously disagreed
on whether bool should be char or unsigned char.
To implement this with minimal invasion of ECPG client namespace,
move the choice of whether to rely on <stdbool.h> into configure,
and have it export a configuration symbol PG_USE_STDBOOL.
ecpglib.h no longer exports definitions for TRUE and FALSE,
only their lowercase brethren. We could undo that if we get
push-back about it.
Ideally we'd back-patch this as far as v11, which is where c.h
started to rely on <stdbool.h>. But the odds of creating problems
for formerly-working ECPG client code seem about as large as the
odds of fixing any non-working cases, so we'll just do this in HEAD.
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
2019-11-13 02:00:04 +08:00
dnl We use <stdbool.h> if we have it and it declares type bool as having
dnl size 1. Otherwise, c.h will fall back to declaring bool as unsigned char.
if test "$ac_cv_header_stdbool_h" = yes -a "$ac_cv_sizeof_bool" = 1; then
AC_DEFINE([PG_USE_STDBOOL], 1,
[Define to 1 to use <stdbool.h> to define type bool.])
fi
2006-01-18 07:52:31 +08:00
2000-07-13 06:59:15 +08:00
##
## Functions, global variables
##
2002-07-28 04:10:05 +08:00
2000-06-11 19:40:09 +08:00
PGAC_VAR_INT_TIMEZONE
2000-07-13 06:59:15 +08:00
AC_FUNC_ACCEPT_ARGTYPES
2000-06-11 19:40:09 +08:00
PGAC_FUNC_GETTIMEOFDAY_1ARG
Cope if platform declares mbstowcs_l(), but not locale_t, in <xlocale.h>.
Previously, we included <xlocale.h> only if necessary to get the definition
of type locale_t. According to notes in PGAC_TYPE_LOCALE_T, this is
important because on some versions of glibc that file supplies an
incompatible declaration of locale_t. (This info may be obsolete, because
on my RHEL6 box that seems to be the *only* definition of locale_t; but
there may still be glibc's in the wild for which it's a live concern.)
It turns out though that on FreeBSD and maybe other BSDen, you can get
locale_t from stdlib.h or locale.h but mbstowcs_l() and friends only from
<xlocale.h>. This was leaving us compiling calls to mbstowcs_l() and
friends with no visible prototype, which causes a warning and could
possibly cause actual trouble, since it's not declared to return int.
Hence, adjust the configure checks so that we'll include <xlocale.h>
either if it's necessary to get type locale_t or if it's necessary to
get a declaration of mbstowcs_l().
Report and patch by Aleksander Alekseev, somewhat whacked around by me.
Back-patch to all supported branches, since we have been using
mbstowcs_l() since 9.1.
2016-03-16 01:19:57 +08:00
PGAC_FUNC_WCSTOMBS_L
1997-02-04 16:53:45 +08:00
2012-12-19 05:22:13 +08:00
# Some versions of libedit contain strlcpy(), setproctitle(), and other
# symbols that that library has no business exposing to the world. Pending
# acquisition of a clue by those developers, ignore libedit (including its
# possible alias of libreadline) while checking for everything else.
LIBS_including_readline="$LIBS"
LIBS=`echo "$LIBS" | sed -e 's/-ledit//g' -e 's/-lreadline//g'`
2018-10-09 12:04:27 +08:00
AC_CHECK_FUNCS(m4_normalize([
2019-11-09 02:44:20 +08:00
backtrace_symbols
2018-10-09 12:04:27 +08:00
clock_gettime
2018-11-08 01:05:54 +08:00
copyfile
2018-10-09 12:04:27 +08:00
fdatasync
getifaddrs
getpeerucred
getrlimit
Add kqueue(2) support to the WaitEventSet API.
Use kevent(2) to wait for events on the BSD family of operating
systems and macOS. This is similar to the epoll(2) support added
for Linux by commit 98a64d0bd.
Author: Thomas Munro
Reviewed-by: Andres Freund, Marko Tiikkaja, Tom Lane
Tested-by: Mateusz Guzik, Matteo Beccati, Keith Fiske, Heikki Linnakangas, Michael Paquier, Peter Eisentraut, Rui DeSousa, Tom Lane, Mark Wong
Discussion: https://postgr.es/m/CAEepm%3D37oF84-iXDTQ9MrGjENwVGds%2B5zTr38ca73kWR7ez_tA%40mail.gmail.com
2020-02-05 12:35:57 +08:00
kqueue
2018-10-09 12:04:27 +08:00
mbstowcs_l
2019-09-05 14:15:58 +08:00
memset_s
2018-10-09 12:04:27 +08:00
poll
posix_fallocate
ppoll
pstat
pthread_is_threaded_np
readlink
setproctitle
setproctitle_fast
setsid
shm_open
strchrnul
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 08:38:57 +08:00
strsignal
2018-10-09 12:04:27 +08:00
symlink
sync_file_range
Avoid thread-safety problem in ecpglib.
ecpglib attempts to force the LC_NUMERIC locale to "C" while reading
server output, to avoid problems with strtod() and related functions.
Historically it's just issued setlocale() calls to do that, but that
has major problems if we're in a threaded application. setlocale()
itself is not required by POSIX to be thread-safe (and indeed is not,
on recent OpenBSD). Moreover, its effects are process-wide, so that
we could cause unexpected results in other threads, or another thread
could change our setting.
On platforms having uselocale(), which is required by POSIX:2008,
we can avoid these problems by using uselocale() instead. Windows
goes its own way as usual, but we can make it safe by using
_configthreadlocale(). Platforms having neither continue to use the
old code, but that should be pretty much nobody among current systems.
This should get back-patched, but let's see what the buildfarm
thinks of it first.
Michael Meskes and Tom Lane; thanks also to Takayuki Tsunakawa.
Discussion: https://postgr.es/m/31420.1547783697@sss.pgh.pa.us
2019-01-22 01:07:02 +08:00
uselocale
2018-10-09 12:04:27 +08:00
wcstombs_l
]))
2001-02-18 12:39:42 +08:00
Make use of compiler builtins and/or assembly for CLZ, CTZ, POPCNT.
Test for the compiler builtins __builtin_clz, __builtin_ctz, and
__builtin_popcount, and make use of these in preference to
handwritten C code if they're available. Create src/port
infrastructure for "leftmost one", "rightmost one", and "popcount"
so as to centralize these decisions.
On x86_64, __builtin_popcount generally won't make use of the POPCNT
opcode because that's not universally supported yet. Provide code
that checks CPUID and then calls POPCNT via asm() if available.
This requires indirecting through a function pointer, which is
an annoying amount of overhead for a one-instruction operation,
but it's probably not worth working harder than this for our
current use-cases.
I'm not sure we've found all the existing places that could profit
from this new infrastructure; but we at least touched all the
ones that used copied-and-pasted versions of the bitmapset.c code,
and got rid of multiple copies of the associated constant arrays.
While at it, replace c-compiler.m4's one-per-builtin-function
macros with a single one that can handle all the cases we need
to worry about so far. Also, because I'm paranoid, make those
checks into AC_LINK checks rather than just AC_COMPILE; the
former coding failed to verify that libgcc has support for the
builtin, in cases where it's not inline code.
David Rowley, Thomas Munro, Alvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/CAKJS1f9WTAGG1tPeJnD18hiQW5gAk59fQ6WK-vfdAKEHyRg2RA@mail.gmail.com
2019-02-16 12:22:27 +08:00
# These typically are compiler builtins, for which AC_CHECK_FUNCS fails.
PGAC_CHECK_BUILTIN_FUNC([__builtin_bswap16], [int x])
PGAC_CHECK_BUILTIN_FUNC([__builtin_bswap32], [int x])
PGAC_CHECK_BUILTIN_FUNC([__builtin_bswap64], [long int x])
# We assume that we needn't test all widths of these explicitly:
PGAC_CHECK_BUILTIN_FUNC([__builtin_clz], [unsigned int x])
PGAC_CHECK_BUILTIN_FUNC([__builtin_ctz], [unsigned int x])
PGAC_CHECK_BUILTIN_FUNC([__builtin_popcount], [unsigned int x])
2020-02-22 01:49:42 +08:00
# We require 64-bit fseeko() to be available, but run this check anyway
# in case it finds that _LARGEFILE_SOURCE has to be #define'd for that.
AC_FUNC_FSEEKO
2010-01-17 03:50:26 +08:00
2009-04-08 06:48:30 +08:00
# posix_fadvise() is a no-op on Solaris, so don't incur function overhead
# by calling it, 2009-04-02
# http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/posix_fadvise.c
2018-11-20 01:01:47 +08:00
dnl must use AS_IF here, else AC_REQUIRES inside AC_CHECK_DECLS malfunctions
AS_IF([test "$PORTNAME" != "solaris"], [
2009-04-08 06:48:30 +08:00
AC_CHECK_FUNCS(posix_fadvise)
2006-06-19 02:30:21 +08:00
AC_CHECK_DECLS(posix_fadvise, [], [], [#include <fcntl.h>])
2018-11-20 01:01:47 +08:00
]) # fi
2009-04-08 06:48:30 +08:00
AC_CHECK_DECLS(fdatasync, [], [], [#include <unistd.h>])
2017-10-11 05:42:16 +08:00
AC_CHECK_DECLS([strlcat, strlcpy, strnlen])
Refer to OS X as "macOS", except for the port name which is still "darwin".
We weren't terribly consistent about whether to call Apple's OS "OS X"
or "Mac OS X", and the former is probably confusing to people who aren't
Apple users. Now that Apple has rebranded it "macOS", follow their lead
to establish a consistent naming pattern. Also, avoid the use of the
ancient project name "Darwin", except as the port code name which does not
seem desirable to change. (In short, this patch touches documentation and
comments, but no actual code.)
I didn't touch contrib/start-scripts/osx/, either. I suspect those are
obsolete and due for a rewrite, anyway.
I dithered about whether to apply this edit to old release notes, but
those were responsible for quite a lot of the inconsistencies, so I ended
up changing them too. Anyway, Apple's being ahistorical about this,
so why shouldn't we be?
2016-09-26 03:40:57 +08:00
# This is probably only present on macOS, but may as well check always
2006-10-02 08:06:18 +08:00
AC_CHECK_DECLS(F_FULLFSYNC, [], [], [#include <fcntl.h>])
2000-05-24 22:58:21 +08:00
2018-09-06 16:07:24 +08:00
AC_CHECK_DECLS([RTLD_GLOBAL, RTLD_NOW], [], [], [#include <dlfcn.h>])
2003-03-29 19:31:52 +08:00
AC_CHECK_TYPE([struct sockaddr_in6],
2018-11-06 23:57:51 +08:00
[AC_DEFINE(HAVE_IPV6, 1, [Define to 1 if you have support for IPv6.])],
2005-08-18 04:20:10 +08:00
[],
2003-01-09 22:35:03 +08:00
[$ac_includes_default
2003-03-29 19:31:52 +08:00
#include <netinet/in.h>])
2003-01-06 13:46:18 +08:00
2000-07-09 21:14:19 +08:00
AC_CACHE_CHECK([for PS_STRINGS], [pgac_cv_var_PS_STRINGS],
2015-07-03 00:21:23 +08:00
[AC_LINK_IFELSE([AC_LANG_PROGRAM(
2000-07-09 21:14:19 +08:00
[#include <machine/vmparam.h>
#include <sys/exec.h>
],
2000-06-04 09:44:38 +08:00
[PS_STRINGS->ps_nargvstr = 1;
2015-07-03 00:21:23 +08:00
PS_STRINGS->ps_argvstr = "foo";])],
2000-07-09 21:14:19 +08:00
[pgac_cv_var_PS_STRINGS=yes],
[pgac_cv_var_PS_STRINGS=no])])
if test "$pgac_cv_var_PS_STRINGS" = yes ; then
2013-06-16 02:11:43 +08:00
AC_DEFINE([HAVE_PS_STRINGS], 1, [Define to 1 if the PS_STRINGS thing exists.])
2000-07-09 21:14:19 +08:00
fi
2000-05-24 22:58:21 +08:00
2018-10-09 12:04:27 +08:00
AC_REPLACE_FUNCS(m4_normalize([
dlopen
2019-09-05 14:15:58 +08:00
explicit_bzero
2018-10-09 12:04:27 +08:00
fls
getopt
2019-10-30 19:58:32 +08:00
getpeereid
2018-10-09 12:04:27 +08:00
getrusage
inet_aton
mkdtemp
2018-11-07 04:50:01 +08:00
pread
pwrite
2018-10-09 12:04:27 +08:00
random
srandom
strlcat
strlcpy
strnlen
2019-02-13 23:19:44 +08:00
strtof
2018-10-09 12:04:27 +08:00
]))
2009-02-12 23:12:47 +08:00
2019-12-19 15:28:37 +08:00
if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
2019-02-16 09:50:16 +08:00
# Cygwin and (apparently, based on test results) Mingw both
# have a broken strtof(), so substitute the same replacement
# code we use with VS2013. That's not a perfect fix, since
# (unlike with VS2013) it doesn't avoid double-rounding, but
# we have no better options. To get that, though, we have to
# force the file to be compiled despite HAVE_STRTOF.
2019-12-19 15:28:37 +08:00
AC_LIBOBJ([strtof])
AC_MSG_NOTICE([On $host_os we will use our strtof wrapper.])
fi
2019-02-16 09:50:16 +08:00
2009-02-12 23:12:47 +08:00
case $host_os in
# Windows uses a specialised env handler
mingw*)
AC_DEFINE(HAVE_UNSETENV, 1, [Define to 1 because replacement version used.])
2011-07-26 11:48:44 +08:00
ac_cv_func_unsetenv=yes
2019-10-30 19:58:32 +08:00
;;
2009-02-12 23:12:47 +08:00
*)
2019-10-30 19:58:32 +08:00
AC_REPLACE_FUNCS([unsetenv])
;;
2009-02-12 23:12:47 +08:00
esac
2005-08-25 10:28:03 +08:00
# System's version of getaddrinfo(), if any, may be used only if we found
# a definition for struct addrinfo; see notes in src/include/getaddrinfo.h.
2014-08-29 08:36:27 +08:00
# We use only our own getaddrinfo.c on Windows, but it's time to revisit that.
if test x"$ac_cv_type_struct_addrinfo" = xyes && \
test "$PORTNAME" != "win32"; then
2006-04-08 01:50:03 +08:00
AC_REPLACE_FUNCS([getaddrinfo])
2003-04-02 08:49:28 +08:00
else
AC_LIBOBJ(getaddrinfo)
fi
2002-07-28 04:10:05 +08:00
2008-02-24 13:21:54 +08:00
# Similarly, use system's getopt_long() only if system provides struct option.
2009-03-28 03:58:11 +08:00
if test x"$ac_cv_type_struct_option" = xyes ; then
2003-08-08 05:11:58 +08:00
AC_REPLACE_FUNCS([getopt_long])
else
AC_LIBOBJ(getopt_long)
fi
2019-01-19 04:06:26 +08:00
# On OpenBSD and Solaris, getopt() doesn't do what we want for long options
# (i.e., allow '-' as a flag character), so use our version on those platforms.
if test "$PORTNAME" = "openbsd" -o "$PORTNAME" = "solaris"; then
2009-03-28 03:58:11 +08:00
AC_LIBOBJ(getopt)
fi
2010-12-16 12:50:41 +08:00
# mingw has adopted a GNU-centric interpretation of optind/optreset,
# so always use our version on Windows.
if test "$PORTNAME" = "win32"; then
AC_LIBOBJ(getopt)
AC_LIBOBJ(getopt_long)
fi
2015-03-16 02:14:24 +08:00
# Win32 (really MinGW) support
2004-09-10 21:53:40 +08:00
if test "$PORTNAME" = "win32"; then
2019-01-22 05:17:10 +08:00
AC_CHECK_FUNCS(_configthreadlocale)
2010-12-16 12:50:41 +08:00
AC_REPLACE_FUNCS(gettimeofday)
2015-03-15 02:08:45 +08:00
AC_LIBOBJ(dirmod)
2010-12-16 12:50:41 +08:00
AC_LIBOBJ(kill)
AC_LIBOBJ(open)
Replace SYSTEMQUOTEs with Windows-specific wrapper functions.
It's easy to forget using SYSTEMQUOTEs when constructing command strings
for system() or popen(). Even if we fix all the places missing it now, it is
bound to be forgotten again in the future. Introduce wrapper functions that
do the the extra quoting for you, and get rid of SYSTEMQUOTEs in all the
callers.
We previosly used SYSTEMQUOTEs in all the hard-coded command strings, and
this doesn't change the behavior of those. But user-supplied commands, like
archive_command, restore_command, COPY TO/FROM PROGRAM calls, as well as
pgbench's \shell, will now gain an extra pair of quotes. That is desirable,
but if you have existing scripts or config files that include an extra
pair of quotes, those might need to be adjusted.
Reviewed by Amit Kapila and Tom Lane
2014-05-05 21:07:40 +08:00
AC_LIBOBJ(system)
2010-12-16 12:50:41 +08:00
AC_LIBOBJ(win32env)
AC_LIBOBJ(win32error)
2016-01-08 05:50:28 +08:00
AC_LIBOBJ(win32security)
2011-09-01 19:02:40 +08:00
AC_LIBOBJ(win32setlocale)
2010-12-16 12:50:41 +08:00
AC_DEFINE([HAVE_SYMLINK], 1,
[Define to 1 if you have the `symlink' function.])
2010-12-26 23:34:47 +08:00
AC_CHECK_TYPES(MINIDUMP_TYPE, [pgac_minidump_type=yes], [pgac_minidump_type=no], [
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <string.h>
#include <dbghelp.h>])
fi
if test x"$pgac_minidump_type" = x"yes" ; then
AC_SUBST(have_win32_dbghelp,yes)
else
AC_SUBST(have_win32_dbghelp,no)
2004-09-10 21:53:40 +08:00
fi
2002-07-20 01:35:11 +08:00
2015-03-16 02:14:24 +08:00
# Cygwin needs only a bit of that
if test "$PORTNAME" = "cygwin"; then
AC_LIBOBJ(dirmod)
fi
2002-12-15 11:16:58 +08:00
AC_CHECK_FUNC(syslog,
2003-04-07 06:45:23 +08:00
[AC_CHECK_HEADER(syslog.h,
[AC_DEFINE(HAVE_SYSLOG, 1, [Define to 1 if you have the syslog interface.])])])
2000-05-31 08:28:42 +08:00
2009-04-05 05:55:50 +08:00
AC_CACHE_CHECK([for opterr], pgac_cv_var_int_opterr,
2015-07-03 00:21:23 +08:00
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <unistd.h>],
[extern int opterr; opterr = 1;])],
2009-04-05 05:55:50 +08:00
[pgac_cv_var_int_opterr=yes],
[pgac_cv_var_int_opterr=no])])
if test x"$pgac_cv_var_int_opterr" = x"yes"; then
AC_DEFINE(HAVE_INT_OPTERR, 1, [Define to 1 if you have the global variable 'int opterr'.])
fi
2000-11-07 06:18:10 +08:00
AC_CACHE_CHECK([for optreset], pgac_cv_var_int_optreset,
2015-07-03 00:21:23 +08:00
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <unistd.h>],
[extern int optreset; optreset = 1;])],
2000-11-07 06:18:10 +08:00
[pgac_cv_var_int_optreset=yes],
[pgac_cv_var_int_optreset=no])])
if test x"$pgac_cv_var_int_optreset" = x"yes"; then
2003-04-07 06:45:23 +08:00
AC_DEFINE(HAVE_INT_OPTRESET, 1, [Define to 1 if you have the global variable 'int optreset'.])
2000-11-07 06:18:10 +08:00
fi
2018-05-20 02:22:18 +08:00
AC_CHECK_FUNCS([strtoll __strtoll strtoq], [break])
AC_CHECK_FUNCS([strtoull __strtoull strtouq], [break])
2018-05-19 10:42:10 +08:00
# strto[u]ll may exist but not be declared
AC_CHECK_DECLS([strtoll, strtoull])
2002-07-28 04:10:05 +08:00
2017-03-24 03:25:34 +08:00
if test "$with_icu" = yes; then
2017-08-05 23:47:28 +08:00
ac_save_CPPFLAGS=$CPPFLAGS
CPPFLAGS="$ICU_CFLAGS $CPPFLAGS"
# Verify we have ICU's header files
AC_CHECK_HEADER(unicode/ucol.h, [],
[AC_MSG_ERROR([header file <unicode/ucol.h> is required for ICU])])
2017-03-24 03:25:34 +08:00
2017-08-05 23:47:28 +08:00
CPPFLAGS=$ac_save_CPPFLAGS
2017-03-24 03:25:34 +08:00
fi
2018-11-20 01:43:05 +08:00
if test "$with_llvm" = yes; then
PGAC_CHECK_LLVM_FUNCTIONS()
fi
2012-12-19 05:22:13 +08:00
# Lastly, restore full LIBS list and check for readline/libedit symbols
LIBS="$LIBS_including_readline"
if test "$with_readline" = yes; then
Improve psql's tab completion for filenames.
The Readline library contains a fair amount of knowledge about how to
tab-complete filenames, but it turns out that that doesn't work too well
unless we follow its expectation that we use its filename quoting hooks
to quote and de-quote filenames. We were trying to do such quote handling
within complete_from_files(), and that's still what we have to do if we're
using libedit, which lacks those hooks. But for Readline, it works a lot
better if we tell Readline that single-quote is a quoting character and
then provide hooks that know the details of the quoting rules for SQL
and psql meta-commands.
Hence, resurrect the quoting hook functions that existed in the original
version of tab-complete.c (and were disabled by commit f6689a328 because
they "didn't work so well yet"), and whack on them until they do seem to
work well.
Notably, this fixes bug #16059 from Steven Winfield, who pointed out
that the previous coding would strip quote marks from filenames in SQL
COPY commands, even though they're syntactically necessary there.
Now, we not only don't do that, but we'll add a quote mark when you
tab-complete, even if you didn't type one.
Getting this to work across a range of libedit versions (and, to a
lesser extent, libreadline versions) was depressingly difficult.
It will be interesting to see whether the new regression test cases
pass everywhere in the buildfarm.
Some future patch might try to handle quoted SQL identifiers with
similar explicit quoting/dequoting logic, but that's for another day.
Patch by me, reviewed by Peter Eisentraut.
Discussion: https://postgr.es/m/16059-8836946734c02b84@postgresql.org
2020-01-24 00:07:12 +08:00
PGAC_READLINE_VARIABLES
Cope with Readline's failure to track SIGWINCH events outside of input.
It emerges that libreadline doesn't notice terminal window size change
events unless they occur while collecting input. This is easy to stumble
over if you resize the window while using a pager to look at query output,
but it can be demonstrated without any pager involvement. The symptom is
that queries exceeding one line are misdisplayed during subsequent input
cycles, because libreadline has the wrong idea of the screen dimensions.
The safest, simplest way to fix this is to call rl_reset_screen_size()
just before calling readline(). That causes an extra ioctl(TIOCGWINSZ)
for every command; but since it only happens when reading from a tty, the
performance impact should be negligible. A more valid objection is that
this still leaves a tiny window during entry to readline() wherein delivery
of SIGWINCH will be missed; but the practical consequences of that are
probably negligible. In any case, there doesn't seem to be any good way to
avoid the race, since readline exposes no functions that seem safe to call
from a generic signal handler --- rl_reset_screen_size() certainly isn't.
It turns out that we also need an explicit rl_initialize() call, else
rl_reset_screen_size() dumps core when called before the first readline()
call.
rl_reset_screen_size() is not present in old versions of libreadline,
so we need a configure test for that. (rl_initialize() is present at
least back to readline 4.0, so we won't bother with a test for it.)
We would need a configure test anyway since libedit's emulation of
libreadline doesn't currently include such a function. Fortunately,
libedit seems not to have any corresponding bug.
Merlin Moncure, adjusted a bit by me
2015-12-17 05:58:55 +08:00
AC_CHECK_FUNCS([rl_completion_matches rl_filename_completion_function rl_reset_screen_size])
2012-12-19 05:22:13 +08:00
AC_CHECK_FUNCS([append_history history_truncate_file])
fi
2002-08-21 01:54:45 +08:00
2001-03-15 02:00:09 +08:00
# This test makes sure that run tests work at all. Sometimes a shared
# library is found by the linker, but the runtime linker can't find it.
# This check should come after all modifications of compiler or linker
# variables, and before any other run tests.
AC_MSG_CHECKING([test program])
2015-07-03 00:21:23 +08:00
AC_RUN_IFELSE([AC_LANG_SOURCE([int main() { return 0; }])],
2001-03-15 02:00:09 +08:00
[AC_MSG_RESULT(ok)],
[AC_MSG_RESULT(failed)
AC_MSG_ERROR([[
2006-10-17 01:24:54 +08:00
Could not execute a simple test program. This may be a problem
related to locating shared libraries. Check the file 'config.log'
for the exact reason.]])],
2001-03-15 02:00:09 +08:00
[AC_MSG_RESULT([cross-compiling])])
2005-12-07 02:35:10 +08:00
# --------------------
# Run tests below here
# --------------------
2001-03-15 02:00:09 +08:00
1999-02-03 08:18:53 +08:00
dnl Check to see if we have a working 64-bit integer type.
2018-05-24 02:19:04 +08:00
dnl Since Postgres 8.4, we no longer support compilers without a working
dnl 64-bit type; but we have to determine whether that type is called
dnl "long int" or "long long int".
2010-01-07 08:25:05 +08:00
2000-06-11 19:40:09 +08:00
PGAC_TYPE_64BIT_INT([long int])
1999-02-03 08:18:53 +08:00
2012-10-08 09:52:07 +08:00
if test x"$HAVE_LONG_INT_64" = x"yes" ; then
pg_int64_type="long int"
else
2000-06-11 19:40:09 +08:00
PGAC_TYPE_64BIT_INT([long long int])
2012-10-08 09:52:07 +08:00
if test x"$HAVE_LONG_LONG_INT_64" = x"yes" ; then
pg_int64_type="long long int"
else
2010-01-07 08:25:05 +08:00
AC_MSG_ERROR([Cannot find a working 64-bit integer type.])
fi
1999-03-08 05:32:06 +08:00
fi
2012-10-08 09:52:07 +08:00
AC_DEFINE_UNQUOTED(PG_INT64_TYPE, $pg_int64_type,
[Define to the name of a signed 64-bit integer type.])
2000-06-11 19:40:09 +08:00
2018-05-24 02:19:04 +08:00
# Select the printf length modifier that goes with that, too.
if test x"$pg_int64_type" = x"long long int" ; then
INT64_MODIFIER='"ll"'
1999-03-15 09:43:07 +08:00
else
2018-05-24 02:19:04 +08:00
INT64_MODIFIER='"l"'
1999-03-08 05:32:06 +08:00
fi
2014-08-21 14:56:44 +08:00
AC_DEFINE_UNQUOTED(INT64_MODIFIER, $INT64_MODIFIER,
2018-05-24 02:19:04 +08:00
[Define to the appropriate printf length modifier for 64-bit ints.])
2004-02-11 03:55:45 +08:00
2017-10-30 13:13:54 +08:00
# has to be down here, rather than with the other builtins, because
# the test uses PG_INT64_TYPE.
PGAC_C_BUILTIN_OP_OVERFLOW
2010-01-01 03:41:37 +08:00
# Check size of void *, size_t (enables tweaks for > 32bit address space)
2009-01-06 23:38:44 +08:00
AC_CHECK_SIZEOF([void *])
2005-08-21 07:26:37 +08:00
AC_CHECK_SIZEOF([size_t])
2010-01-01 03:41:37 +08:00
AC_CHECK_SIZEOF([long])
2005-08-21 07:26:37 +08:00
2002-03-30 01:32:55 +08:00
# Determine memory alignment requirements for the basic C data types.
1999-03-26 03:05:19 +08:00
2008-02-18 00:36:43 +08:00
AC_CHECK_ALIGNOF(short)
AC_CHECK_ALIGNOF(int)
AC_CHECK_ALIGNOF(long)
2002-03-30 01:32:55 +08:00
if test x"$HAVE_LONG_LONG_INT_64" = x"yes" ; then
2008-02-18 00:36:43 +08:00
AC_CHECK_ALIGNOF(long long int)
1999-03-26 03:05:19 +08:00
fi
2008-02-18 00:36:43 +08:00
AC_CHECK_ALIGNOF(double)
1999-03-26 03:05:19 +08:00
2002-03-30 01:32:55 +08:00
# Compute maximum alignment of any basic type.
# We assume long's alignment is at least as strong as char, short, or int;
2017-11-15 04:03:55 +08:00
# but we must check long long (if it is being used for int64) and double.
# Note that we intentionally do not consider any types wider than 64 bits,
# as allowing MAXIMUM_ALIGNOF to exceed 8 would be too much of a penalty
# for disk and memory space.
1999-03-26 03:05:19 +08:00
2008-02-18 00:36:43 +08:00
MAX_ALIGNOF=$ac_cv_alignof_long
if test $MAX_ALIGNOF -lt $ac_cv_alignof_double ; then
MAX_ALIGNOF=$ac_cv_alignof_double
2002-03-30 01:32:55 +08:00
fi
2008-02-18 00:36:43 +08:00
if test x"$HAVE_LONG_LONG_INT_64" = xyes && test $MAX_ALIGNOF -lt $ac_cv_alignof_long_long_int ; then
MAX_ALIGNOF="$ac_cv_alignof_long_long_int"
1999-03-26 03:05:19 +08:00
fi
2003-04-07 06:45:23 +08:00
AC_DEFINE_UNQUOTED(MAXIMUM_ALIGNOF, $MAX_ALIGNOF, [Define as the maximum alignment requirement of any C data type.])
2000-06-11 19:40:09 +08:00
2001-12-02 19:38:40 +08:00
2001-11-16 00:09:34 +08:00
# Some platforms predefine the types int8, int16, etc. Only check
2002-03-30 01:32:55 +08:00
# a (hopefully) representative subset.
AC_CHECK_TYPES([int8, uint8, int64, uint64], [], [],
2012-05-14 09:47:48 +08:00
[#include <stdio.h>])
2001-12-02 19:38:40 +08:00
2017-11-15 04:03:55 +08:00
# Some compilers offer a 128-bit integer scalar type.
Add, optional, support for 128bit integers.
We will, for the foreseeable future, not expose 128 bit datatypes to
SQL. But being able to use 128bit math will allow us, in a later patch,
to use 128bit accumulators for some aggregates; leading to noticeable
speedups over using numeric.
So far we only detect a gcc/clang extension that supports 128bit math,
but no 128bit literals, and no *printf support. We might want to expand
this in the future to further compilers; if there are any that that
provide similar support.
Discussion: 544BB5F1.50709@proxel.se
Author: Andreas Karlsson, with significant editorializing by me
Reviewed-By: Peter Geoghegan, Oskari Saarenmaa
2015-03-20 17:26:17 +08:00
PGAC_TYPE_128BIT_INT
Add a basic atomic ops API abstracting away platform/architecture details.
Several upcoming performance/scalability improvements require atomic
operations. This new API avoids the need to splatter compiler and
architecture dependent code over all the locations employing atomic
ops.
For several of the potential usages it'd be problematic to maintain
both, a atomics using implementation and one using spinlocks or
similar. In all likelihood one of the implementations would not get
tested regularly under concurrency. To avoid that scenario the new API
provides a automatic fallback of atomic operations to spinlocks. All
properties of atomic operations are maintained. This fallback -
obviously - isn't as fast as just using atomic ops, but it's not bad
either. For one of the future users the atomics ontop spinlocks
implementation was actually slightly faster than the old purely
spinlock using implementation. That's important because it reduces the
fear of regressing older platforms when improving the scalability for
new ones.
The API, loosely modeled after the C11 atomics support, currently
provides 'atomic flags' and 32 bit unsigned integers. If the platform
efficiently supports atomic 64 bit unsigned integers those are also
provided.
To implement atomics support for a platform/architecture/compiler for
a type of atomics 32bit compare and exchange needs to be
implemented. If available and more efficient native support for flags,
32 bit atomic addition, and corresponding 64 bit operations may also
be provided. Additional useful atomic operations are implemented
generically ontop of these.
The implementation for various versions of gcc, msvc and sun studio have
been tested. Additional existing stub implementations for
* Intel icc
* HUPX acc
* IBM xlc
are included but have never been tested. These will likely require
fixes based on buildfarm and user feedback.
As atomic operations also require barriers for some operations the
existing barrier support has been moved into the atomics code.
Author: Andres Freund with contributions from Oskari Saarenmaa
Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
20131015123303.GH5300@awork2.anarazel.de,
20131028205522.GI20248@awork2.anarazel.de
2014-09-26 05:49:05 +08:00
# Check for various atomic operations now that we have checked how to declare
# 64bit integers.
PGAC_HAVE_GCC__SYNC_CHAR_TAS
PGAC_HAVE_GCC__SYNC_INT32_TAS
PGAC_HAVE_GCC__SYNC_INT32_CAS
PGAC_HAVE_GCC__SYNC_INT64_CAS
PGAC_HAVE_GCC__ATOMIC_INT32_CAS
PGAC_HAVE_GCC__ATOMIC_INT64_CAS
2001-11-16 00:09:34 +08:00
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
# Check for x86 cpuid instruction
AC_CACHE_CHECK([for __get_cpuid], [pgac_cv__get_cpuid],
2015-07-03 00:21:23 +08:00
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <cpuid.h>],
[[unsigned int exx[4] = {0, 0, 0, 0};
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
__get_cpuid(1, &exx[0], &exx[1], &exx[2], &exx[3]);
2015-07-03 00:21:23 +08:00
]])],
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
[pgac_cv__get_cpuid="yes"],
[pgac_cv__get_cpuid="no"])])
if test x"$pgac_cv__get_cpuid" = x"yes"; then
AC_DEFINE(HAVE__GET_CPUID, 1, [Define to 1 if you have __get_cpuid.])
fi
AC_CACHE_CHECK([for __cpuid], [pgac_cv__cpuid],
2015-07-03 00:21:23 +08:00
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <intrin.h>],
[[unsigned int exx[4] = {0, 0, 0, 0};
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
__get_cpuid(exx[0], 1);
2015-07-03 00:21:23 +08:00
]])],
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
[pgac_cv__cpuid="yes"],
[pgac_cv__cpuid="no"])])
if test x"$pgac_cv__cpuid" = x"yes"; then
AC_DEFINE(HAVE__CPUID, 1, [Define to 1 if you have __cpuid.])
fi
# Check for Intel SSE 4.2 intrinsics to do CRC calculations.
#
2015-04-15 00:56:03 +08:00
# First check if the _mm_crc32_u8 and _mm_crc32_u64 intrinsics can be used
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
# with the default compiler flags. If not, check if adding the -msse4.2
# flag helps. CFLAGS_SSE42 is set to -msse4.2 if that's required.
PGAC_SSE42_CRC32_INTRINSICS([])
if test x"$pgac_sse42_crc32_intrinsics" != x"yes"; then
PGAC_SSE42_CRC32_INTRINSICS([-msse4.2])
fi
AC_SUBST(CFLAGS_SSE42)
2015-04-15 00:56:03 +08:00
# Are we targeting a processor that supports SSE 4.2? gcc, clang and icc all
# define __SSE4_2__ in that case.
2015-07-03 00:21:23 +08:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [
2015-04-15 00:56:03 +08:00
#ifndef __SSE4_2__
#error __SSE4_2__ not defined
#endif
2015-07-03 00:21:23 +08:00
])], [SSE4_2_TARGETED=1])
2015-04-15 00:56:03 +08:00
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
# Check for ARMv8 CRC Extension intrinsics to do CRC calculations.
#
# First check if __crc32c* intrinsics can be used with the default compiler
# flags. If not, check if adding -march=armv8-a+crc flag helps.
# CFLAGS_ARMV8_CRC32C is set if the extra flag is required.
PGAC_ARMV8_CRC32C_INTRINSICS([])
if test x"$pgac_armv8_crc32c_intrinsics" != x"yes"; then
PGAC_ARMV8_CRC32C_INTRINSICS([-march=armv8-a+crc])
fi
AC_SUBST(CFLAGS_ARMV8_CRC32C)
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
# Select CRC-32C implementation.
#
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
# If we are targeting a processor that has Intel SSE 4.2 instructions, we can
# use the special CRC instructions for calculating CRC-32C. If we're not
# targeting such a processor, but we can nevertheless produce code that uses
# the SSE intrinsics, perhaps with some extra CFLAGS, compile both
# implementations and select which one to use at runtime, depending on whether
# SSE 4.2 is supported by the processor we're running on.
#
# Similarly, if we are targeting an ARM processor that has the CRC
# instructions that are part of the ARMv8 CRC Extension, use them. And if
# we're not targeting such a processor, but can nevertheless produce code that
# uses the CRC instructions, compile both, and select at runtime.
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
#
# You can override this logic by setting the appropriate USE_*_CRC32 flag to 1
# in the template or configure command line.
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
if test x"$USE_SLICING_BY_8_CRC32C" = x"" && test x"$USE_SSE42_CRC32C" = x"" && test x"$USE_SSE42_CRC32C_WITH_RUNTIME_CHECK" = x"" && test x"$USE_ARMV8_CRC32C" = x"" && test x"$USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK" = x""; then
# Use Intel SSE 4.2 if available.
2015-04-15 00:56:03 +08:00
if test x"$pgac_sse42_crc32_intrinsics" = x"yes" && test x"$SSE4_2_TARGETED" = x"1" ; then
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
USE_SSE42_CRC32C=1
else
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
# Intel SSE 4.2, with runtime check? The CPUID instruction is needed for
# the runtime check.
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
if test x"$pgac_sse42_crc32_intrinsics" = x"yes" && (test x"$pgac_cv__get_cpuid" = x"yes" || test x"$pgac_cv__cpuid" = x"yes"); then
USE_SSE42_CRC32C_WITH_RUNTIME_CHECK=1
else
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
# Use ARM CRC Extension if available.
if test x"$pgac_armv8_crc32c_intrinsics" = x"yes" && test x"$CFLAGS_ARMV8_CRC32C" = x""; then
USE_ARMV8_CRC32C=1
else
2018-05-03 06:06:43 +08:00
# ARM CRC Extension, with runtime check?
if test x"$pgac_armv8_crc32c_intrinsics" = x"yes"; then
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK=1
else
# fall back to slicing-by-8 algorithm, which doesn't require any
# special CPU support.
USE_SLICING_BY_8_CRC32C=1
fi
fi
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
fi
fi
fi
# Set PG_CRC32C_OBJS appropriately depending on the selected implementation.
AC_MSG_CHECKING([which CRC-32C implementation to use])
if test x"$USE_SSE42_CRC32C" = x"1"; then
AC_DEFINE(USE_SSE42_CRC32C, 1, [Define to 1 use Intel SSE 4.2 CRC instructions.])
PG_CRC32C_OBJS="pg_crc32c_sse42.o"
AC_MSG_RESULT(SSE 4.2)
else
if test x"$USE_SSE42_CRC32C_WITH_RUNTIME_CHECK" = x"1"; then
2018-04-04 16:20:53 +08:00
AC_DEFINE(USE_SSE42_CRC32C_WITH_RUNTIME_CHECK, 1, [Define to 1 to use Intel SSE 4.2 CRC instructions with a runtime check.])
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
PG_CRC32C_OBJS="pg_crc32c_sse42.o pg_crc32c_sb8.o pg_crc32c_sse42_choose.o"
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
AC_MSG_RESULT(SSE 4.2 with runtime check)
else
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be supported by the compiler, and the instructions must be supported by the
target architecture. If the compilation target architecture does not
support the instructions, but adding "-march=armv8-a+crc" makes them
available, then we compile the code with a runtime check to determine if
the host we're running on supports them or not.
For the runtime check, use glibc getauxval() function. Unfortunately,
that's not very portable, but I couldn't find any more portable way to do
it. If getauxval() is not available, the CRC instructions will still be
used if the target architecture supports them without any additional
compiler flags, but the runtime check will not be available.
Original patch by Yuqi Gu, heavily modified by me. Reviewed by Andres
Freund, Thomas Munro.
Discussion: https://www.postgresql.org/message-id/HE1PR0801MB1323D171938EABC04FFE7FA9E3110%40HE1PR0801MB1323.eurprd08.prod.outlook.com
2018-04-04 17:22:45 +08:00
if test x"$USE_ARMV8_CRC32C" = x"1"; then
AC_DEFINE(USE_ARMV8_CRC32C, 1, [Define to 1 to use ARMv8 CRC Extension.])
PG_CRC32C_OBJS="pg_crc32c_armv8.o"
AC_MSG_RESULT(ARMv8 CRC instructions)
else
if test x"$USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK" = x"1"; then
AC_DEFINE(USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK, 1, [Define to 1 to use ARMv8 CRC Extension with a runtime check.])
PG_CRC32C_OBJS="pg_crc32c_armv8.o pg_crc32c_sb8.o pg_crc32c_armv8_choose.o"
AC_MSG_RESULT(ARMv8 CRC instructions with runtime check)
else
AC_DEFINE(USE_SLICING_BY_8_CRC32C, 1, [Define to 1 to use software CRC-32C implementation (slicing-by-8).])
PG_CRC32C_OBJS="pg_crc32c_sb8.o"
AC_MSG_RESULT(slicing-by-8)
fi
fi
Use Intel SSE 4.2 CRC instructions where available.
Modern x86 and x86-64 processors with SSE 4.2 support have special
instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
speed up CRC calculation.
Whether the instructions can be used or not depends on the compiler and the
target architecture. If generation of SSE 4.2 instructions is allowed for
the target (-msse4.2 flag on gcc and clang), use them. If they are not
allowed by default, but the compiler supports the -msse4.2 flag to enable
them, compile just the CRC-32C function with -msse4.2 flag, and check at
runtime whether the processor we're running on supports it. If it doesn't,
fall back to the slicing-by-8 algorithm. (With the common defaults on
current operating systems, the runtime-check variant is what you get in
practice.)
Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.
2015-04-14 22:05:03 +08:00
fi
fi
AC_SUBST(PG_CRC32C_OBJS)
2002-05-05 08:03:29 +08:00
# Select semaphore implementation type.
2006-04-30 00:34:41 +08:00
if test "$PORTNAME" != "win32"; then
Use unnamed POSIX semaphores, if available, on Linux and FreeBSD.
We've had support for using unnamed POSIX semaphores instead of System V
semaphores for quite some time, but it was not used by default on any
platform. Since many systems have rather small limits on the number of
SysV semaphores allowed, it seems desirable to switch to POSIX semaphores
where they're available and don't create performance or kernel resource
problems. Experimentation by me shows that unnamed POSIX semaphores
are at least as good as SysV semaphores on Linux, and we previously had
a report from Maksym Sobolyev that FreeBSD is significantly worse with
SysV semaphores than POSIX ones. So adjust those two platforms to use
unnamed POSIX semaphores, if configure can find the necessary library
functions. If this goes well, we may switch other platforms as well,
but it would be advisable to test them individually first.
It's not currently contemplated that we'd encourage users to select
a semaphore API for themselves, but anyone who wants to experiment
can add PREFERRED_SEMAPHORES=UNNAMED_POSIX (or NAMED_POSIX, or SYSV)
to their configure command line to do so.
I also tweaked configure to report which API it's selected, mainly
so that we can tell that from buildfarm reports.
I did not touch the user documentation's discussion about semaphores;
that will need some adjustment once the dust settles.
Discussion: <8536.1475704230@sss.pgh.pa.us>
2016-10-10 06:03:45 +08:00
if test x"$PREFERRED_SEMAPHORES" = x"NAMED_POSIX" ; then
# Need sem_open for this
AC_SEARCH_LIBS(sem_open, [rt pthread], [USE_NAMED_POSIX_SEMAPHORES=1])
fi
if test x"$PREFERRED_SEMAPHORES" = x"UNNAMED_POSIX" ; then
# Need sem_init for this
AC_SEARCH_LIBS(sem_init, [rt pthread], [USE_UNNAMED_POSIX_SEMAPHORES=1])
fi
AC_MSG_CHECKING([which semaphore API to use])
2006-04-30 00:34:41 +08:00
if test x"$USE_NAMED_POSIX_SEMAPHORES" = x"1" ; then
AC_DEFINE(USE_NAMED_POSIX_SEMAPHORES, 1, [Define to select named POSIX semaphores.])
2002-05-05 08:03:29 +08:00
SEMA_IMPLEMENTATION="src/backend/port/posix_sema.c"
Use unnamed POSIX semaphores, if available, on Linux and FreeBSD.
We've had support for using unnamed POSIX semaphores instead of System V
semaphores for quite some time, but it was not used by default on any
platform. Since many systems have rather small limits on the number of
SysV semaphores allowed, it seems desirable to switch to POSIX semaphores
where they're available and don't create performance or kernel resource
problems. Experimentation by me shows that unnamed POSIX semaphores
are at least as good as SysV semaphores on Linux, and we previously had
a report from Maksym Sobolyev that FreeBSD is significantly worse with
SysV semaphores than POSIX ones. So adjust those two platforms to use
unnamed POSIX semaphores, if configure can find the necessary library
functions. If this goes well, we may switch other platforms as well,
but it would be advisable to test them individually first.
It's not currently contemplated that we'd encourage users to select
a semaphore API for themselves, but anyone who wants to experiment
can add PREFERRED_SEMAPHORES=UNNAMED_POSIX (or NAMED_POSIX, or SYSV)
to their configure command line to do so.
I also tweaked configure to report which API it's selected, mainly
so that we can tell that from buildfarm reports.
I did not touch the user documentation's discussion about semaphores;
that will need some adjustment once the dust settles.
Discussion: <8536.1475704230@sss.pgh.pa.us>
2016-10-10 06:03:45 +08:00
sematype="named POSIX"
2002-05-05 08:03:29 +08:00
else
2006-04-30 00:34:41 +08:00
if test x"$USE_UNNAMED_POSIX_SEMAPHORES" = x"1" ; then
AC_DEFINE(USE_UNNAMED_POSIX_SEMAPHORES, 1, [Define to select unnamed POSIX semaphores.])
SEMA_IMPLEMENTATION="src/backend/port/posix_sema.c"
Use unnamed POSIX semaphores, if available, on Linux and FreeBSD.
We've had support for using unnamed POSIX semaphores instead of System V
semaphores for quite some time, but it was not used by default on any
platform. Since many systems have rather small limits on the number of
SysV semaphores allowed, it seems desirable to switch to POSIX semaphores
where they're available and don't create performance or kernel resource
problems. Experimentation by me shows that unnamed POSIX semaphores
are at least as good as SysV semaphores on Linux, and we previously had
a report from Maksym Sobolyev that FreeBSD is significantly worse with
SysV semaphores than POSIX ones. So adjust those two platforms to use
unnamed POSIX semaphores, if configure can find the necessary library
functions. If this goes well, we may switch other platforms as well,
but it would be advisable to test them individually first.
It's not currently contemplated that we'd encourage users to select
a semaphore API for themselves, but anyone who wants to experiment
can add PREFERRED_SEMAPHORES=UNNAMED_POSIX (or NAMED_POSIX, or SYSV)
to their configure command line to do so.
I also tweaked configure to report which API it's selected, mainly
so that we can tell that from buildfarm reports.
I did not touch the user documentation's discussion about semaphores;
that will need some adjustment once the dust settles.
Discussion: <8536.1475704230@sss.pgh.pa.us>
2016-10-10 06:03:45 +08:00
sematype="unnamed POSIX"
2006-04-30 00:34:41 +08:00
else
AC_DEFINE(USE_SYSV_SEMAPHORES, 1, [Define to select SysV-style semaphores.])
SEMA_IMPLEMENTATION="src/backend/port/sysv_sema.c"
Use unnamed POSIX semaphores, if available, on Linux and FreeBSD.
We've had support for using unnamed POSIX semaphores instead of System V
semaphores for quite some time, but it was not used by default on any
platform. Since many systems have rather small limits on the number of
SysV semaphores allowed, it seems desirable to switch to POSIX semaphores
where they're available and don't create performance or kernel resource
problems. Experimentation by me shows that unnamed POSIX semaphores
are at least as good as SysV semaphores on Linux, and we previously had
a report from Maksym Sobolyev that FreeBSD is significantly worse with
SysV semaphores than POSIX ones. So adjust those two platforms to use
unnamed POSIX semaphores, if configure can find the necessary library
functions. If this goes well, we may switch other platforms as well,
but it would be advisable to test them individually first.
It's not currently contemplated that we'd encourage users to select
a semaphore API for themselves, but anyone who wants to experiment
can add PREFERRED_SEMAPHORES=UNNAMED_POSIX (or NAMED_POSIX, or SYSV)
to their configure command line to do so.
I also tweaked configure to report which API it's selected, mainly
so that we can tell that from buildfarm reports.
I did not touch the user documentation's discussion about semaphores;
that will need some adjustment once the dust settles.
Discussion: <8536.1475704230@sss.pgh.pa.us>
2016-10-10 06:03:45 +08:00
sematype="System V"
2006-04-30 00:34:41 +08:00
fi
2002-05-05 08:03:29 +08:00
fi
2016-12-07 08:34:29 +08:00
AC_MSG_RESULT([$sematype])
2006-04-30 00:34:41 +08:00
else
AC_DEFINE(USE_WIN32_SEMAPHORES, 1, [Define to select Win32-style semaphores.])
SEMA_IMPLEMENTATION="src/backend/port/win32_sema.c"
2002-05-05 08:03:29 +08:00
fi
# Select shared-memory implementation type.
2007-03-21 22:39:23 +08:00
if test "$PORTNAME" != "win32"; then
AC_DEFINE(USE_SYSV_SHARED_MEMORY, 1, [Define to select SysV-style shared memory.])
SHMEM_IMPLEMENTATION="src/backend/port/sysv_shmem.c"
else
AC_DEFINE(USE_WIN32_SHARED_MEMORY, 1, [Define to select Win32-style shared memory.])
SHMEM_IMPLEMENTATION="src/backend/port/win32_shmem.c"
fi
2002-05-05 08:03:29 +08:00
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 19:42:59 +08:00
# Select random number source
#
# You can override this logic by setting the appropriate USE_*RANDOM flag to 1
# in the template or configure command line.
# If not selected manually, try to select a source automatically.
2019-01-01 19:05:51 +08:00
if test x"$USE_OPENSSL_RANDOM" = x"" && test x"$USE_WIN32_RANDOM" = x"" && test x"$USE_DEV_URANDOM" = x"" ; then
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 19:42:59 +08:00
if test x"$with_openssl" = x"yes" ; then
USE_OPENSSL_RANDOM=1
2016-12-12 15:26:42 +08:00
elif test "$PORTNAME" = "win32" ; then
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 19:42:59 +08:00
USE_WIN32_RANDOM=1
else
AC_CHECK_FILE([/dev/urandom], [], [])
if test x"$ac_cv_file__dev_urandom" = x"yes" ; then
USE_DEV_URANDOM=1
fi
fi
fi
AC_MSG_CHECKING([which random number source to use])
2019-01-01 19:05:51 +08:00
if test x"$USE_OPENSSL_RANDOM" = x"1" ; then
AC_DEFINE(USE_OPENSSL_RANDOM, 1, [Define to use OpenSSL for random number generation])
AC_MSG_RESULT([OpenSSL])
elif test x"$USE_WIN32_RANDOM" = x"1" ; then
AC_DEFINE(USE_WIN32_RANDOM, 1, [Define to use native Windows API for random number generation])
AC_MSG_RESULT([Windows native])
elif test x"$USE_DEV_URANDOM" = x"1" ; then
AC_DEFINE(USE_DEV_URANDOM, 1, [Define to use /dev/urandom for random number generation])
AC_MSG_RESULT([/dev/urandom])
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 19:42:59 +08:00
else
2019-01-01 19:05:51 +08:00
AC_MSG_ERROR([
no source of strong random numbers was found
PostgreSQL can use OpenSSL or /dev/urandom as a source of random numbers.])
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 19:42:59 +08:00
fi
2006-02-03 21:53:15 +08:00
# If not set in template file, set bytes to use libc memset()
if test x"$MEMSET_LOOP_LIMIT" = x"" ; then
MEMSET_LOOP_LIMIT=1024
fi
AC_DEFINE_UNQUOTED(MEMSET_LOOP_LIMIT, ${MEMSET_LOOP_LIMIT}, [Define bytes to use libc memset().])
2002-03-30 08:20:15 +08:00
if test "$enable_nls" = yes ; then
PGAC_CHECK_GETTEXT
fi
2000-09-26 06:23:01 +08:00
# Check for Tcl configuration script tclConfig.sh
if test "$with_tcl" = yes; then
PGAC_PATH_TCLCONFIGSH([$with_tclconfig])
2002-05-25 02:10:17 +08:00
PGAC_EVAL_TCLCONFIGSH([$TCL_CONFIG_SH],
Move interpreter shared library detection to configure
For building PL/Perl, PL/Python, and PL/Tcl, we need a shared library of
libperl, libpython, and libtcl, respectively. Previously, this was
checked in the makefiles, skipping the PL build with a warning if no
shared library was available. Now this is checked in configure, with an
error if no shared library is available.
The previous situation arose because in the olden days, the configure
options --with-perl, --with-python, and --with-tcl controlled whether
frontend interfaces for those languages would be built. The procedural
languages were added later, and shared libraries were often not
available in the beginning. So it was decided skip the builds of the
procedural languages in those cases. The frontend interfaces have since
been removed from the tree, and shared libraries are now available most
of the time, so that setup makes much less sense now.
Also, the new setup allows contrib modules and pgxs users to rely on the
respective PLs being available based on configure flags.
2015-05-02 09:38:21 +08:00
[TCL_INCLUDE_SPEC,TCL_LIBS,TCL_LIB_SPEC,TCL_SHARED_BUILD])
2002-05-25 02:10:17 +08:00
AC_SUBST(TCL_SHLIB_LD_LIBS)dnl don't want to double-evaluate that one
Move interpreter shared library detection to configure
For building PL/Perl, PL/Python, and PL/Tcl, we need a shared library of
libperl, libpython, and libtcl, respectively. Previously, this was
checked in the makefiles, skipping the PL build with a warning if no
shared library was available. Now this is checked in configure, with an
error if no shared library is available.
The previous situation arose because in the olden days, the configure
options --with-perl, --with-python, and --with-tcl controlled whether
frontend interfaces for those languages would be built. The procedural
languages were added later, and shared libraries were often not
available in the beginning. So it was decided skip the builds of the
procedural languages in those cases. The frontend interfaces have since
been removed from the tree, and shared libraries are now available most
of the time, so that setup makes much less sense now.
Also, the new setup allows contrib modules and pgxs users to rely on the
respective PLs being available based on configure flags.
2015-05-02 09:38:21 +08:00
if test "$TCL_SHARED_BUILD" != 1; then
AC_MSG_ERROR([cannot build PL/Tcl because Tcl is not a shared library
Use --without-tcl to disable building PL/Tcl.])
fi
2004-12-17 04:41:01 +08:00
# now that we have TCL_INCLUDE_SPEC, we can check for <tcl.h>
ac_save_CPPFLAGS=$CPPFLAGS
CPPFLAGS="$TCL_INCLUDE_SPEC $CPPFLAGS"
AC_CHECK_HEADER(tcl.h, [], [AC_MSG_ERROR([header file <tcl.h> is required for Tcl])])
CPPFLAGS=$ac_save_CPPFLAGS
1998-10-15 23:58:16 +08:00
fi
2013-01-10 08:41:37 +08:00
# check for <perl.h>
if test "$with_perl" = yes; then
ac_save_CPPFLAGS=$CPPFLAGS
Still further rethinking of build changes for macOS Mojave.
To avoid the sorts of problems complained of by Jakob Egger, it'd be
best if configure didn't emit any references to the sysroot path at all.
In the case of PL/Tcl, we can do that just by keeping our hands off the
TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to
substitute -iwithsysroot for -I in the compile commands, which is easily
handled if we change to using a configure output variable that includes
the switch not only the directory name. Since PL/Tcl and PL/Python
already do it like that, this seems like good consistency cleanup anyway.
Hence, this replaces the advice given to Perl-related extensions in commit
5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should
just write "$(perl_includespec)". (The old way continues to work, but not
on recent macOS.)
It's still the case that configure needs to be aware of the sysroot
path internally, but that's cleaner than what we had before.
As before, back-patch to all supported versions.
Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
2018-10-19 02:55:23 +08:00
CPPFLAGS="$CPPFLAGS $perl_includespec"
2013-01-10 08:41:37 +08:00
AC_CHECK_HEADER(perl.h, [], [AC_MSG_ERROR([header file <perl.h> is required for Perl])],
[#include <EXTERN.h>])
# While we're at it, check that we can link to libperl.
# On most platforms, if perl.h is there then libperl.so will be too, but at
# this writing Debian packages them separately. There is no known reason to
# waste cycles on separate probes for the Tcl or Python libraries, though.
2019-10-22 01:52:25 +08:00
# On some Red Hat platforms, the link attempt can fail if we don't use
# CFLAGS_SL while building the test program.
ac_save_CFLAGS=$CFLAGS
CFLAGS="$CFLAGS $CFLAGS_SL"
2013-01-10 08:41:37 +08:00
pgac_save_LIBS=$LIBS
2013-01-10 12:46:44 +08:00
LIBS="$perl_embed_ldflags"
2013-01-10 08:41:37 +08:00
AC_MSG_CHECKING([for libperl])
2015-07-03 00:21:23 +08:00
AC_LINK_IFELSE([AC_LANG_PROGRAM([
2013-01-10 08:41:37 +08:00
#include <EXTERN.h>
#include <perl.h>
2015-07-03 00:21:23 +08:00
], [perl_alloc();])],
2013-01-10 08:41:37 +08:00
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
AC_MSG_ERROR([libperl library is required for Perl])])
LIBS=$pgac_save_LIBS
2019-10-22 01:52:25 +08:00
CFLAGS=$ac_save_CFLAGS
2013-01-10 08:41:37 +08:00
CPPFLAGS=$ac_save_CPPFLAGS
fi
2011-02-27 03:17:57 +08:00
# check for <Python.h>
if test "$with_python" = yes; then
ac_save_CPPFLAGS=$CPPFLAGS
CPPFLAGS="$python_includespec $CPPFLAGS"
AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file <Python.h> is required for Python])])
CPPFLAGS=$ac_save_CPPFLAGS
fi
2000-11-06 05:04:07 +08:00
#
# Check for DocBook and tools
#
2017-11-23 22:39:47 +08:00
PGAC_PATH_XMLLINT
2019-08-13 14:38:21 +08:00
PGAC_CHECK_DOCBOOK(4.5)
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
PGAC_PATH_PROGS(DBTOEPUB, dbtoepub)
PGAC_PATH_PROGS(XSLTPROC, xsltproc)
PGAC_PATH_PROGS(FOP, fop)
2000-11-06 05:04:07 +08:00
2014-04-15 09:33:46 +08:00
#
# Check for test tools
#
2014-11-02 22:14:36 +08:00
if test "$enable_tap_tests" = yes; then
2017-08-08 04:42:18 +08:00
# Check for necessary modules, unless user has specified the "prove" to use;
# in that case it's her responsibility to have a working configuration.
# (prove might be part of a different Perl installation than perl, eg on
# MSys, so the result of AX_PROG_PERL_MODULES could be irrelevant anyway.)
if test -z "$PROVE"; then
2018-03-21 03:16:16 +08:00
# Test::More and Time::HiRes are supposed to be part of core Perl,
# but some distros omit them in a minimal installation.
AX_PROG_PERL_MODULES([IPC::Run Test::More=0.87 Time::HiRes], ,
[AC_MSG_ERROR([Additional Perl modules are required to run TAP tests])])
2017-08-08 04:42:18 +08:00
fi
# Now make sure we know where prove is
Further improve consistency of configure's program searching.
Peter Eisentraut noted that commit 40b9f1921 had broken a configure
behavior that some people might rely on: AC_CHECK_PROGS(FOO,...) will
allow the search to be overridden by specifying a value for FOO on
configure's command line or in its environment, but AC_PATH_PROGS(FOO,...)
accepts such an override only if it's an absolute path. We had worked
around that behavior for some, but not all, of the pre-existing uses
of AC_PATH_PROGS by just skipping the macro altogether when FOO is
already set. Let's standardize on that workaround for all uses of
AC_PATH_PROGS, new and pre-existing, by wrapping AC_PATH_PROGS in a
new macro PGAC_PATH_PROGS. While at it, fix a deficiency of the old
workaround code by making sure we report the setting to configure's log.
Eventually I'd like to improve PGAC_PATH_PROGS so that it converts
non-absolute override inputs to absolute form, eg "PYTHON=python3"
becomes, say, PYTHON = /usr/bin/python3. But that will take some
nontrivial coding so it doesn't seem like a thing to do in late beta.
Discussion: https://postgr.es/m/90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
2017-08-01 23:40:00 +08:00
PGAC_PATH_PROGS(PROVE, prove)
2014-11-02 22:14:36 +08:00
if test -z "$PROVE"; then
AC_MSG_ERROR([prove not found])
fi
fi
2014-04-15 09:33:46 +08:00
2004-04-28 03:51:12 +08:00
# Thread testing
# We have to run the thread test near the end so we have all our symbols
# defined. Cross compiling throws a warning.
#
2009-12-02 22:07:26 +08:00
if test "$enable_thread_safety" = yes; then
2007-03-27 05:30:56 +08:00
if test "$PORTNAME" != "win32"
2005-08-24 05:02:05 +08:00
then
2004-04-28 03:51:12 +08:00
AC_MSG_CHECKING([thread safety of required library functions])
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE"
LIBS="$LIBS $PTHREAD_LIBS"
2015-07-03 00:21:23 +08:00
AC_RUN_IFELSE(
[AC_LANG_SOURCE([[#include "$srcdir/src/test/thread/thread_test.c"]])],
2004-04-28 03:51:12 +08:00
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
2006-10-17 01:24:54 +08:00
AC_MSG_ERROR([thread test program failed
2009-12-02 22:07:26 +08:00
This platform is not thread-safe. Check the file 'config.log' or compile
and run src/test/thread/thread_test for the exact reason.
Use --disable-thread-safety to disable thread safety.])],
2004-04-28 03:51:12 +08:00
[AC_MSG_RESULT(maybe)
AC_MSG_WARN([
*** Skipping thread test program because of cross-compile build.
2006-02-04 09:00:02 +08:00
*** Run the program in src/test/thread on the target machine.
2004-04-28 03:51:12 +08:00
])])
CFLAGS="$_CFLAGS"
LIBS="$_LIBS"
2005-08-24 05:02:05 +08:00
else
2006-10-17 01:24:54 +08:00
AC_MSG_WARN([*** skipping thread test on Win32])
2005-08-24 05:02:05 +08:00
fi
2004-04-28 03:51:12 +08:00
fi
1999-05-12 06:57:50 +08:00
2009-06-11 05:24:11 +08:00
# If compiler will take -Wl,--as-needed (or various platform-specific
# spellings thereof) then add that to LDFLAGS. This is much easier than
# trying to filter LIBS to the minimum for each executable.
2008-05-20 11:30:22 +08:00
# On (at least) some Red-Hat-derived systems, this switch breaks linking to
# libreadline; therefore we postpone testing it until we know what library
# dependencies readline has. The test code will try to link with $LIBS.
if test "$with_readline" = yes; then
link_test_func=readline
else
link_test_func=exit
fi
2009-06-11 05:24:11 +08:00
if test "$PORTNAME" = "darwin"; then
2008-05-20 11:30:22 +08:00
PGAC_PROG_CC_LDFLAGS_OPT([-Wl,-dead_strip_dylibs], $link_test_func)
2009-06-11 05:24:11 +08:00
elif test "$PORTNAME" = "openbsd"; then
PGAC_PROG_CC_LDFLAGS_OPT([-Wl,-Bdynamic], $link_test_func)
else
PGAC_PROG_CC_LDFLAGS_OPT([-Wl,--as-needed], $link_test_func)
2008-05-20 11:30:22 +08:00
fi
2009-01-06 23:38:44 +08:00
# Create compiler version string
if test x"$GCC" = x"yes" ; then
2011-05-07 03:14:53 +08:00
cc_string=`${CC} --version | sed q`
case $cc_string in [[A-Za-z]]*) ;; *) cc_string="GCC $cc_string";; esac
2009-01-07 18:38:44 +08:00
elif test x"$SUN_STUDIO_CC" = x"yes" ; then
cc_string=`${CC} -V 2>&1 | sed q`
2009-01-06 23:38:44 +08:00
else
cc_string=$CC
fi
AC_DEFINE_UNQUOTED(PG_VERSION_STR,
2013-12-13 10:53:21 +08:00
["PostgreSQL $PG_VERSION on $host, compiled by $cc_string, `expr $ac_cv_sizeof_void_p \* 8`-bit"],
2009-01-06 23:38:44 +08:00
[A string containing the version number, platform, and C compiler])
# Supply a numeric version string for use by 3rd party add-ons
# awk -F is a regex on some platforms, and not on others, so make "." a tab
[PG_VERSION_NUM="`echo "$PACKAGE_VERSION" | sed 's/[A-Za-z].*$//' |
tr '.' ' ' |
2017-11-07 08:46:52 +08:00
$AWK '{printf "%d%04d", $1, $2}'`"]
2009-01-06 23:38:44 +08:00
AC_DEFINE_UNQUOTED(PG_VERSION_NUM, $PG_VERSION_NUM, [PostgreSQL version as a number])
2015-07-03 05:24:36 +08:00
AC_SUBST(PG_VERSION_NUM)
2009-01-06 23:38:44 +08:00
2018-11-03 06:54:00 +08:00
# If we are inserting PG_SYSROOT into CPPFLAGS, do so symbolically not
# literally, so that it's possible to override it at build time using
# a command like "make ... PG_SYSROOT=path". This has to be done after
# we've finished all configure checks that depend on CPPFLAGS.
if test x"$PG_SYSROOT" != x; then
CPPFLAGS=`echo "$CPPFLAGS" | sed -e "s| $PG_SYSROOT | \\\$(PG_SYSROOT) |"`
fi
AC_SUBST(PG_SYSROOT)
2009-01-06 23:38:44 +08:00
2011-08-29 05:14:52 +08:00
# Begin output steps
AC_MSG_NOTICE([using compiler=$cc_string])
AC_MSG_NOTICE([using CFLAGS=$CFLAGS])
AC_MSG_NOTICE([using CPPFLAGS=$CPPFLAGS])
AC_MSG_NOTICE([using LDFLAGS=$LDFLAGS])
2018-03-21 08:26:25 +08:00
# Currently only used when LLVM is used
if test "$with_llvm" = yes ; then
AC_MSG_NOTICE([using CXX=$CXX])
AC_MSG_NOTICE([using CXXFLAGS=$CXXFLAGS])
AC_MSG_NOTICE([using CLANG=$CLANG])
AC_MSG_NOTICE([using BITCODE_CFLAGS=$BITCODE_CFLAGS])
AC_MSG_NOTICE([using BITCODE_CXXFLAGS=$BITCODE_CXXFLAGS])
fi
2011-08-29 05:14:52 +08:00
2001-03-03 23:53:41 +08:00
# prepare build tree if outside source tree
2001-09-11 07:52:04 +08:00
# Note 1: test -ef might not exist, but it's more reliable than `pwd`.
# Note 2: /bin/pwd might be better than shell's built-in at getting
# a symlink-free name.
2003-11-28 02:14:02 +08:00
if ( test "$srcdir" -ef . ) >/dev/null 2>&1 || test "`cd $srcdir && /bin/pwd`" = "`/bin/pwd`"; then
vpath_build=no
else
vpath_build=yes
if test "$no_create" != yes; then
2002-03-30 01:32:55 +08:00
_AS_ECHO_N([preparing build tree... ])
pgac_abs_top_srcdir=`cd "$srcdir" && pwd`
$SHELL "$ac_aux_dir/prep_buildtree" "$pgac_abs_top_srcdir" "." \
2001-03-03 23:53:41 +08:00
|| AC_MSG_ERROR(failed)
AC_MSG_RESULT(done)
2002-03-30 01:32:55 +08:00
fi
2000-10-21 05:04:27 +08:00
fi
2003-11-28 02:14:02 +08:00
AC_SUBST(vpath_build)
2000-10-21 05:04:27 +08:00
2002-03-30 01:32:55 +08:00
AC_CONFIG_FILES([GNUmakefile src/Makefile.global])
AC_CONFIG_LINKS([
2002-05-05 08:03:29 +08:00
src/backend/port/pg_sema.c:${SEMA_IMPLEMENTATION}
src/backend/port/pg_shmem.c:${SHMEM_IMPLEMENTATION}
2002-03-30 01:32:55 +08:00
src/include/pg_config_os.h:src/include/port/${template}.h
src/Makefile.port:src/makefiles/Makefile.${template}
])
2004-09-10 21:53:40 +08:00
if test "$PORTNAME" = "win32"; then
2004-05-18 12:10:33 +08:00
AC_CONFIG_COMMANDS([check_win32_symlinks],[
2010-11-24 04:27:50 +08:00
# Links sometimes fail undetected on Mingw -
2004-05-13 09:45:02 +08:00
# so here we detect it and warn the user
2004-05-29 04:52:42 +08:00
for FILE in $CONFIG_LINKS
2004-05-13 09:45:02 +08:00
do
# test -e works for symlinks in the MinGW console
2006-10-17 01:24:54 +08:00
test -e `expr "$FILE" : '\([[^:]]*\)'` || AC_MSG_WARN([*** link for $FILE -- please fix by hand])
2004-05-13 09:45:02 +08:00
done
2004-05-18 03:14:47 +08:00
])
2004-09-10 21:53:40 +08:00
fi
2004-05-13 09:45:02 +08:00
2004-05-18 03:14:47 +08:00
AC_CONFIG_HEADERS([src/include/pg_config.h],
[
# Update timestamp for pg_config.h (see Makefile.global)
echo >src/include/stamp-h
])
2012-10-08 09:52:07 +08:00
AC_CONFIG_HEADERS([src/include/pg_config_ext.h],
[
# Update timestamp for pg_config_ext.h (see Makefile.global)
echo >src/include/stamp-ext-h
])
2009-01-23 06:27:13 +08:00
AC_CONFIG_HEADERS([src/interfaces/ecpg/include/ecpg_config.h],
[echo >src/interfaces/ecpg/include/stamp-h])
2006-08-23 20:01:53 +08:00
2004-05-18 03:14:47 +08:00
AC_OUTPUT