2003-09-27 20:24:45 +04:00
dnl Process this file with autoconf to produce a configure script.
2020-07-24 11:34:16 +03:00
dnl configure.ac
2002-05-24 22:10:17 +04:00
dnl
2000-07-09 17:14:19 +04: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 09:08:06 +04:00
dnl 3. Header files
2000-07-09 17:14:19 +04: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-24 22:10:17 +04:00
dnl
m4_pattern_forbid(^PGAC_)dnl to catch undefined macros
2003-11-24 17:52:58 +03:00
2024-07-01 01:56:10 +03:00
AC_INIT([PostgreSQL], [18devel], [pgsql-bugs@lists.postgresql.org], [], [https://www.postgresql.org/])
2002-03-29 20:32:55 +03:00
2013-12-19 05:53:23 +04:00
m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.69], [], [m4_fatal([Autoconf version 2.69 is required.
2007-12-31 20:28:21 +03:00
Untested combinations of 'autoconf' and PostgreSQL versions are not
2020-07-24 11:34:16 +03:00
recommended. You can remove the check from 'configure.ac' but it is then
2007-12-31 20:28:21 +03:00
your responsibility whether the result works or not.])])
2024-01-04 04:49:05 +03:00
AC_COPYRIGHT([Copyright (c) 1996-2024, PostgreSQL Global Development Group])
2002-03-29 20:32:55 +03:00
AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c])
2000-07-09 17:14:19 +04:00
AC_CONFIG_AUX_DIR(config)
2002-03-29 20:32:55 +03:00
AC_PREFIX_DEFAULT(/usr/local/pgsql)
2020-02-10 19:12:46 +03:00
AC_DEFINE_UNQUOTED(CONFIGURE_ARGS, ["$ac_configure_args"], [Saved arguments from configure])
2000-06-10 22:02:12 +04:00
2016-08-15 20:49:49 +03:00
[PG_MAJORVERSION=`expr "$PACKAGE_VERSION" : '\([0-9][0-9]*\)'`]
2020-03-10 13:20:38 +03:00
[PG_MINORVERSION=`expr "$PACKAGE_VERSION" : '.*\.\([0-9][0-9]*\)'`]
test -n "$PG_MINORVERSION" || PG_MINORVERSION=0
2008-12-11 10:34:09 +03:00
AC_SUBST(PG_MAJORVERSION)
AC_DEFINE_UNQUOTED(PG_MAJORVERSION, "$PG_MAJORVERSION", [PostgreSQL major version as a string])
2020-03-10 13:20:38 +03:00
AC_DEFINE_UNQUOTED(PG_MAJORVERSION_NUM, $PG_MAJORVERSION, [PostgreSQL major version number])
AC_DEFINE_UNQUOTED(PG_MINORVERSION_NUM, $PG_MINORVERSION, [PostgreSQL minor version number])
2000-10-21 01:04:27 +04:00
2013-12-13 06:53:21 +04: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 01:26:36 +04:00
AC_CANONICAL_HOST
1998-02-04 16:19:32 +03:00
2000-07-15 19:54:52 +04:00
template=
AC_MSG_CHECKING([which template to use])
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, template, [NAME], [override operating system template],
2000-09-22 00:17:43 +04:00
[
case $withval in
2000-07-15 19:54:52 +04:00
list) echo; ls "$srcdir/src/template"; exit;;
*) if test -f "$srcdir/src/template/$with_template" ; then
2000-09-22 00:17:43 +04:00
template=$withval
2000-07-15 19:54:52 +04:00
else
2000-11-26 21:15:42 +03:00
AC_MSG_ERROR(['$withval' is not a valid template name. Use 'list' for a list.])
2000-07-15 19:54:52 +04:00
fi;;
esac
2000-09-22 00:17:43 +04:00
],
[
2003-08-11 22:07:38 +04:00
# --with-template not given
2000-07-15 19:54:52 +04:00
case $host_os in
2019-12-19 10:28:37 +03:00
cygwin*|msys*) template=cygwin ;;
2000-10-31 22:55:20 +03:00
darwin*) template=darwin ;;
2011-03-02 22:15:28 +03:00
dragonfly*) template=netbsd ;;
2000-07-15 19:54:52 +04:00
freebsd*) template=freebsd ;;
2004-09-18 02:31:59 +04:00
linux*|gnu*|k*bsd*-gnu)
template=linux ;;
2003-05-15 20:35:30 +04:00
mingw*) template=win32 ;;
2000-07-15 19:54:52 +04:00
netbsd*) template=netbsd ;;
openbsd*) template=openbsd ;;
2000-10-11 01:22:29 +04:00
solaris*) template=solaris ;;
1997-02-04 11:53:45 +03:00
esac
1997-04-09 12:55:32 +04:00
2000-07-15 19:54:52 +04:00
if test x"$template" = x"" ; then
2000-11-26 21:15:42 +03:00
AC_MSG_ERROR([[
2000-07-15 19:54:52 +04:00
*******************************************************************
PostgreSQL has apparently not been ported to your platform yet.
2000-07-18 02:31:59 +04:00
To try a manual configuration, look into the src/template directory
2000-11-26 21:15:42 +03:00
for a similar platform and use the '--with-template=' option.
2000-07-15 19:54:52 +04:00
2020-02-28 10:54:49 +03:00
Please also contact <]AC_PACKAGE_BUGREPORT[> to see about
2000-11-26 21:15:42 +03:00
rectifying this. Include the above 'checking host system type...'
2000-07-15 19:54:52 +04:00
line.
*******************************************************************
2000-11-26 21:15:42 +03:00
]])
2000-07-15 19:54:52 +04:00
fi
1998-10-30 07:54:06 +03:00
2000-09-22 00:17:43 +04:00
])
1998-02-04 16:19:32 +03:00
2000-07-15 19:54:52 +04:00
AC_MSG_RESULT([$template])
1998-10-23 06:49:17 +04:00
2000-07-15 19:54:52 +04:00
PORTNAME=$template
AC_SUBST(PORTNAME)
1999-12-17 21:18:26 +03:00
2003-12-23 21:40:53 +03: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 12:55:32 +04:00
2022-03-25 10:44:31 +03:00
# Default, works for most platforms, override in template file if needed
DLSUFFIX=".so"
1998-12-13 23:03:07 +03:00
1997-04-09 12:55:32 +04:00
2000-07-15 19:54:52 +04:00
##
## Command line options
##
2000-06-17 04:10:40 +04:00
2000-07-15 19:54:52 +04:00
#
# Add non-standard directories to the include path
#
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, includes, [DIRS], [look for additional header files in DIRS])
1997-04-09 12:55:32 +04:00
1998-04-10 06:59:38 +04:00
2000-07-15 19:54:52 +04:00
#
# Add non-standard directories to the library search path
#
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, libraries, [DIRS], [look for additional libraries in DIRS],
2000-09-22 00:17:43 +04:00
[LIBRARY_DIRS=$withval])
1997-04-09 12:55:32 +04:00
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, libs, [DIRS], [alternative spelling of --with-libraries],
2000-09-22 00:17:43 +04:00
[LIBRARY_DIRS=$withval])
2000-06-07 20:27:00 +04:00
1997-04-09 12:55:32 +04:00
2000-07-13 02:59:15 +04:00
#
2017-02-23 19:40:12 +03: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-21 23:56:30 +04:00
#
2017-02-23 19:40:12 +03: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-21 23:56:30 +04:00
2001-06-02 22:25:18 +04:00
#
# NLS
#
AC_MSG_CHECKING([whether NLS is wanted])
PGAC_ARG_OPTARG(enable, nls,
2008-10-29 12:27:24 +03:00
[LANGUAGES], [enable Native Language Support],
2001-06-02 22:25:18 +04:00
[],
[WANTED_LANGUAGES=$enableval],
2002-03-29 20:32:55 +03:00
[AC_DEFINE(ENABLE_NLS, 1,
2003-04-07 02:45:23 +04:00
[Define to 1 if you want National Language Support. (--enable-nls)])])
2001-06-02 22:25:18 +04:00
AC_MSG_RESULT([$enable_nls])
AC_SUBST(enable_nls)
AC_SUBST(WANTED_LANGUAGES)
2000-07-13 02:59:15 +04:00
#
# Default port number (--with-pgport), default 5432
#
AC_MSG_CHECKING([for default port number])
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, pgport, [PORTNUM], [set default port number [5432]],
2000-09-22 00:17:43 +04:00
[default_port=$withval],
[default_port=5432])
2001-02-07 23:13:27 +03:00
AC_MSG_RESULT([$default_port])
# Need both of these because some places want an integer and some a string
2002-03-29 20:32:55 +03:00
AC_DEFINE_UNQUOTED(DEF_PGPORT, ${default_port},
2003-04-07 02:45:23 +04:00
[Define to the default TCP port number on which the server listens and
2003-08-11 22:07:38 +04: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-29 20:32:55 +03:00
AC_DEFINE_UNQUOTED(DEF_PGPORT_STR, "${default_port}",
2003-08-11 22:07:38 +04:00
[Define to the default TCP port number as a string constant.])
2001-02-07 23:13:27 +03:00
AC_SUBST(default_port)
1997-04-09 12:55:32 +04:00
2016-03-14 17:41:29 +03: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 03:59:39 +04:00
#
# '-rpath'-like feature can be disabled
#
PGAC_ARG_BOOL(enable, rpath, yes,
2008-10-29 12:27:24 +03:00
[do not embed shared library search path in executables])
2000-10-28 03:59:39 +04:00
AC_SUBST(enable_rpath)
2003-09-13 21:01:09 +04:00
#
# Spinlocks
#
PGAC_ARG_BOOL(enable, spinlocks, yes,
2008-10-29 12:27:24 +03:00
[do not use spinlocks])
2000-10-24 01:44:12 +04: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 01:49:05 +04:00
#
# Atomic operations
#
PGAC_ARG_BOOL(enable, atomics, yes,
[do not use atomic operations])
2000-11-04 17:29:26 +03:00
#
# --enable-debug adds -g to compiler flags
#
PGAC_ARG_BOOL(enable, debug, no,
2008-10-29 12:27:24 +03:00
[build with debugging symbols (-g)])
2002-03-05 20:55:23 +03:00
AC_SUBST(enable_debug)
2000-11-04 17:29:26 +03:00
2007-02-21 18:12:39 +03:00
#
# --enable-profiling enables gcc profiling
#
PGAC_ARG_BOOL(enable, profiling, no,
2008-10-29 12:27:24 +03:00
[build with profiling enabled ])
2007-02-21 18:12:39 +03:00
2008-09-05 16:11:18 +04:00
#
# --enable-coverage enables generation of code coverage metrics with gcov
#
PGAC_ARG_BOOL(enable, coverage, no,
2008-10-29 12:27:24 +03: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 18:40:00 +03:00
[PGAC_PATH_PROGS(GCOV, gcov)
2008-09-05 16:11:18 +04: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 18:40:00 +03:00
PGAC_PATH_PROGS(LCOV, lcov)
2008-09-05 16:11:18 +04: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 18:40:00 +03:00
PGAC_PATH_PROGS(GENHTML, genhtml)
2008-09-05 16:11:18 +04:00
if test -z "$GENHTML"; then
AC_MSG_ERROR([genhtml not found])
2008-09-05 22:54:58 +04:00
fi])
2008-09-05 16:11:18 +04:00
AC_SUBST(enable_coverage)
2006-07-24 20:32:45 +04:00
#
# DTrace
#
PGAC_ARG_BOOL(enable, dtrace, no,
2008-10-29 12:27:24 +03: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 18:40:00 +03:00
[PGAC_PATH_PROGS(DTRACE, dtrace)
2006-08-17 21:25:43 +04:00
if test -z "$DTRACE"; then
AC_MSG_ERROR([dtrace not found])
fi
2006-07-24 20:32:45 +04:00
AC_SUBST(DTRACEFLAGS)])
AC_SUBST(enable_dtrace)
2014-11-02 17:14:36 +03:00
#
# TAP tests
#
PGAC_ARG_BOOL(enable, tap-tests, no,
[enable TAP tests (requires Perl and IPC::Run)])
AC_SUBST(enable_tap_tests)
Add backend support for injection points
Injection points are a new facility that makes possible for developers
to run custom code in pre-defined code paths. Its goal is to provide
ways to design and run advanced tests, for cases like:
- Race conditions, where processes need to do actions in a controlled
ordered manner.
- Forcing a state, like an ERROR, FATAL or even PANIC for OOM, to force
recovery, etc.
- Arbitrary sleeps.
This implements some basics, and there are plans to extend it more in
the future depending on what's required. Hence, this commit adds a set
of routines in the backend that allows developers to attach, detach and
run injection points:
- A code path calling an injection point can be declared with the macro
INJECTION_POINT(name).
- InjectionPointAttach() and InjectionPointDetach() to respectively
attach and detach a callback to/from an injection point. An injection
point name is registered in a shmem hash table with a library name and a
function name, which will be used to load the callback attached to an
injection point when its code path is run.
Injection point names are just strings, so as an injection point can be
declared and run by out-of-core extensions and modules, with callbacks
defined in external libraries.
This facility is hidden behind a dedicated switch for ./configure and
meson, disabled by default.
Note that backends use a local cache to store callbacks already loaded,
cleaning up their cache if a callback has found to be removed on a
best-effort basis. This could be refined further but any tests but what
we have here was fine with the tests I've written while implementing
these backend APIs.
Author: Michael Paquier, with doc suggestions from Ashutosh Bapat.
Reviewed-by: Ashutosh Bapat, Nathan Bossart, Álvaro Herrera, Dilip
Kumar, Amul Sul, Nazir Bilal Yavuz
Discussion: https://postgr.es/m/ZTiV8tn_MIb_H2rE@paquier.xyz
2024-01-22 04:15:50 +03:00
#
# Injection points
#
PGAC_ARG_BOOL(enable, injection-points, no, [enable injection points (for testing)],
[AC_DEFINE([USE_INJECTION_POINTS], 1, [Define to 1 to build with injection points. (--enable-injection-points)])])
AC_SUBST(enable_injection_points)
2008-03-10 23:06:27 +03:00
#
2008-05-02 05:08:27 +04:00
# Block size
#
AC_MSG_CHECKING([for block size])
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, blocksize, [BLOCKSIZE], [set table block size in kB [8]],
2008-05-02 05:08:27 +04: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-23 23:27:50 +03:00
2008-05-02 05:08:27 +04: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-23 23:27:50 +03:00
2008-05-02 05:08:27 +04:00
Changing BLCKSZ requires an initdb.
2010-11-23 23:27:50 +03:00
])
2008-05-02 05:08:27 +04:00
#
2008-05-02 23:52:37 +04:00
# Relation segment size
2008-05-02 05:08:27 +04:00
#
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, segsize, [SEGSIZE], [set table segment size in GB [1]],
2008-05-02 05:08:27 +04:00
[segsize=$withval],
[segsize=1])
2022-12-08 06:32:59 +03:00
PGAC_ARG_REQ(with, segsize-blocks, [SEGSIZE_BLOCKS], [set table segment size in blocks [0]],
[segsize_blocks=$withval],
[segsize_blocks=0])
# If --with-segsize-blocks is non-zero, it is used, --with-segsize
# otherwise. segsize-blocks is only really useful for developers wanting to
# test segment related code. Warn if both are used.
if test $segsize_blocks -ne 0 -a $segsize -ne 1; then
AC_MSG_WARN([both --with-segsize and --with-segsize-blocks specified, --with-segsize-blocks wins])
fi
AC_MSG_CHECKING([for segment size])
if test $segsize_blocks -eq 0; then
# this expression is set up to avoid unnecessary integer overflow
# blocksize is already guaranteed to be a factor of 1024
RELSEG_SIZE=`expr '(' 1024 / ${blocksize} ')' '*' ${segsize} '*' 1024`
test $? -eq 0 || exit 1
AC_MSG_RESULT([${segsize}GB])
else
RELSEG_SIZE=$segsize_blocks
AC_MSG_RESULT([${RELSEG_SIZE} blocks])
fi
2008-05-02 05:08:27 +04:00
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-23 23:27:50 +03:00
2008-05-02 05:08:27 +04: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-10 23:06:27 +03:00
2008-05-02 23:52:37 +04:00
#
# WAL block size
#
AC_MSG_CHECKING([for WAL block size])
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, wal-blocksize, [BLOCKSIZE], [set WAL block size in kB [8]],
2008-05-02 23:52:37 +04: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-23 23:27:50 +03:00
])
2008-05-02 23:52:37 +04:00
2000-07-13 02:59:15 +04:00
#
2000-07-15 19:54:52 +04:00
# C compiler
#
Remove AIX support
There isn't a lot of user demand for AIX support, we have a bunch of
hacks to work around AIX-specific compiler bugs and idiosyncrasies,
and no one has stepped up to the plate to properly maintain it.
Remove support for AIX to get rid of that maintenance overhead. It's
still supported for stable versions.
The acute issue that triggered this decision was that after commit
8af2565248, the AIX buildfarm members have been hitting this
assertion:
TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer)"), File: "md.c", Line: 472, PID: 2949728
Apperently the "pg_attribute_aligned(a)" attribute doesn't work on AIX
for values larger than PG_IO_ALIGN_SIZE, for a static const variable.
That could be worked around, but we decided to just drop the AIX support
instead.
Discussion: https://www.postgresql.org/message-id/20240224172345.32@rfd.leadboat.com
Reviewed-by: Andres Freund, Noah Misch, Thomas Munro
2024-02-28 14:10:51 +03:00
# If you don't specify a list of compilers to test, the AC_PROG_CC and
# AC_PROG_CXX macros test for a long list of unsupported compilers.
pgac_cc_list="gcc cc"
pgac_cxx_list="g++ c++"
2000-11-04 17:29:26 +03:00
2002-03-29 20:32:55 +03:00
AC_PROG_CC([$pgac_cc_list])
2018-08-16 11:32:05 +03:00
AC_PROG_CC_C99()
2018-08-24 04:33:40 +03: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 01:41:15 +03:00
AC_PROG_CXX([$pgac_cxx_list])
2003-08-11 22:07:38 +04:00
2007-08-05 19:43:00 +04: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-02 19:21:23 +03:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@ifndef __INTEL_COMPILER
2007-08-05 19:43:00 +04:00
choke me
2015-07-02 19:21:23 +03:00
@%:@endif])], [ICC=yes], [ICC=no])
2007-08-05 19:43:00 +04:00
2008-10-29 19:06:47 +03:00
# Check if it's Sun Studio compiler. We assume that
# __SUNPRO_C will be defined for Sun Studio compilers
2015-07-02 19:21:23 +03:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@ifndef __SUNPRO_C
2008-10-29 19:06:47 +03:00
choke me
2015-07-02 19:21:23 +03:00
@%:@endif])], [SUN_STUDIO_CC=yes], [SUN_STUDIO_CC=no])
2008-10-29 19:06:47 +03:00
AC_SUBST(SUN_STUDIO_CC)
2018-03-21 03:26:25 +03: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 07:16:00 +03:00
dnl must use AS_IF here, else AC_REQUIRES inside PGAC_LLVM_SUPPORT malfunctions
2018-11-19 20:01:47 +03:00
AS_IF([test "$with_llvm" = yes], [
PGAC_LLVM_SUPPORT()
]) # fi
2018-03-21 03:26:25 +03:00
2003-11-01 23:48:51 +03:00
unset CFLAGS
2018-03-22 04:40:23 +03:00
unset CXXFLAGS
2003-10-25 19:32:11 +04:00
2003-08-11 22:07:38 +04:00
#
2000-07-15 19:54:52 +04:00
# Read the template
2003-08-11 22:07:38 +04:00
#
2000-07-15 19:54:52 +04:00
. "$srcdir/src/template/$template" || exit
2000-11-04 17:29:26 +03:00
2018-03-21 01:41:15 +03:00
# C[XX]FLAGS are selected so:
2003-10-25 19:32:11 +04: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 16:11:18 +04:00
# else: If coverage was enabled, don't set anything.
2003-10-25 19:32:11 +04:00
# else: If the compiler is GCC, then we use -O2.
2009-02-11 23:02:40 +03:00
# else: If the compiler is something else, then we use -O, unless debugging.
2003-10-25 19:32:11 +04:00
2002-03-29 20:32:55 +03:00
if test "$ac_env_CFLAGS_set" = set; then
CFLAGS=$ac_env_CFLAGS_value
2003-11-01 23:48:51 +03:00
elif test "${CFLAGS+set}" = set; then
2003-10-25 19:32:11 +04:00
: # (keep what template set)
2008-09-05 16:11:18 +04:00
elif test "$enable_coverage" = yes; then
: # no optimization by default
2003-10-25 19:32:11 +04:00
elif test "$GCC" = yes; then
CFLAGS="-O2"
2003-10-14 04:48:09 +04:00
else
2003-11-01 23:48:51 +03:00
# if the user selected debug mode, don't use -O
if test "$enable_debug" != yes; then
CFLAGS="-O"
fi
2000-11-04 17:29:26 +03:00
fi
2003-10-25 19:32:11 +04:00
2018-03-21 01:41:15 +03: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 03:26:25 +03:00
# When generating bitcode (for inlining) we always want to use -O2
2021-11-18 22:50:13 +03:00
# even when --enable-debug is specified. The bitcode is not going to
2018-03-21 03:26:25 +03:00
# 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 04:41:08 +03:00
BITCODE_CXXFLAGS="-O2 $BITCODE_CXXFLAGS"
2018-03-21 03:26:25 +03:00
fi
2018-03-21 01:41:15 +03:00
# C[XX]FLAGS we determined above will be added back at the end
2015-01-14 19:08:13 +03:00
user_CFLAGS=$CFLAGS
CFLAGS=""
2018-03-21 01:41:15 +03:00
user_CXXFLAGS=$CXXFLAGS
CXXFLAGS=""
2018-03-21 03:26:25 +03:00
user_BITCODE_CFLAGS=$BITCODE_CFLAGS
BITCODE_CFLAGS=""
user_BITCODE_CXXFLAGS=$BITCODE_CXXFLAGS
BITCODE_CXXFLAGS=""
2015-01-14 19:08:13 +03:00
2020-09-07 04:28:16 +03:00
# set CFLAGS_UNROLL_LOOPS and CFLAGS_VECTORIZE from the environment, if present
if test "$ac_env_CFLAGS_UNROLL_LOOPS_set" = set; then
CFLAGS_UNROLL_LOOPS=$ac_env_CFLAGS_UNROLL_LOOPS_value
fi
if test "$ac_env_CFLAGS_VECTORIZE_set" = set; then
CFLAGS_VECTORIZE=$ac_env_CFLAGS_VECTORIZE_value
2013-04-30 09:59:26 +04:00
fi
2006-04-30 00:47:31 +04: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-11 23:02:40 +03: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 06:12:07 +04:00
2007-08-05 19:43:00 +04:00
if test "$GCC" = yes -a "$ICC" = no; then
2015-01-14 19:08:13 +03:00
CFLAGS="-Wall -Wmissing-prototypes -Wpointer-arith"
2018-03-21 01:41:15 +03:00
CXXFLAGS="-Wall -Wpointer-arith"
2007-08-05 19:43:00 +04: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 18:20:33 +03:00
save_CFLAGS=$CFLAGS
2007-08-05 19:43:00 +04: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 18:20:33 +03: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 00:12:28 +03: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 18:20:33 +03:00
PERMIT_DECLARATION_AFTER_STATEMENT=-Wno-declaration-after-statement
fi
AC_SUBST(PERMIT_DECLARATION_AFTER_STATEMENT)
2018-08-24 04:33:40 +03:00
# Really don't want VLAs to be used in our dialect of C
PGAC_PROG_CC_CFLAGS_OPT([-Werror=vla])
2021-07-13 02:17:35 +03:00
# On macOS, complain about usage of symbols newer than the deployment target
PGAC_PROG_CC_CFLAGS_OPT([-Werror=unguarded-availability-new])
PGAC_PROG_CXX_CFLAGS_OPT([-Werror=unguarded-availability-new])
2018-08-24 04:33:40 +03:00
# -Wvla is not applicable for C++
2007-08-05 19:43:00 +04:00
PGAC_PROG_CC_CFLAGS_OPT([-Wendif-labels])
2018-03-21 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-Wendif-labels])
2011-09-11 00:12:46 +04:00
PGAC_PROG_CC_CFLAGS_OPT([-Wmissing-format-attribute])
2018-03-21 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-Wmissing-format-attribute])
2020-05-13 22:31:14 +03:00
PGAC_PROG_CC_CFLAGS_OPT([-Wimplicit-fallthrough=3])
PGAC_PROG_CXX_CFLAGS_OPT([-Wimplicit-fallthrough=3])
Fix -Wcast-function-type warnings
Three groups of issues needed to be addressed:
load_external_function() and related functions returned PGFunction,
even though not necessarily all callers are looking for a function of
type PGFunction. Since these functions are really just wrappers
around dlsym(), change to return void * just like dlsym().
In dynahash.c, we are using strlcpy() where a function with a
signature like memcpy() is expected. This should be safe, as the new
comment there explains, but the cast needs to be augmented to avoid
the warning.
In PL/Python, methods all need to be cast to PyCFunction, per Python
API, but this now runs afoul of these warnings. (This issue also
exists in core CPython.)
To fix the second and third case, we add a new type pg_funcptr_t that
is defined specifically so that gcc accepts it as a special function
pointer that can be cast to any other function pointer without the
warning.
Also add -Wcast-function-type to the standard warning flags, subject
to configure check.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/1e97628e-6447-b4fd-e230-d109cec2d584%402ndquadrant.com
2020-07-14 20:36:30 +03:00
PGAC_PROG_CC_CFLAGS_OPT([-Wcast-function-type])
PGAC_PROG_CXX_CFLAGS_OPT([-Wcast-function-type])
2022-10-07 06:50:31 +03:00
PGAC_PROG_CC_CFLAGS_OPT([-Wshadow=compatible-local])
PGAC_PROG_CXX_CFLAGS_OPT([-Wshadow=compatible-local])
2011-01-27 02:23:48 +03:00
# This was included in -Wall/-Wformat in older GCC versions
PGAC_PROG_CC_CFLAGS_OPT([-Wformat-security])
2018-03-21 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-Wformat-security])
2004-10-20 06:12:07 +04:00
# Disable strict-aliasing rules; needed for gcc 3.3+
PGAC_PROG_CC_CFLAGS_OPT([-fno-strict-aliasing])
2018-03-21 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-fno-strict-aliasing])
2008-03-11 00:50:16 +03:00
# Disable optimizations that assume no overflow; needed for gcc 4.3+
PGAC_PROG_CC_CFLAGS_OPT([-fwrapv])
2018-03-21 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-fwrapv])
2011-12-15 02:15:24 +04: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 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-fexcess-precision=standard])
2020-09-07 04:28:16 +03:00
# Optimization flags for specific files that benefit from loop unrolling
PGAC_PROG_CC_VAR_OPT(CFLAGS_UNROLL_LOOPS, [-funroll-loops])
2013-04-30 09:59:26 +04:00
# Optimization flags for specific files that benefit from vectorization
2020-09-07 04:28:16 +03:00
PGAC_PROG_CC_VAR_OPT(CFLAGS_VECTORIZE, [-ftree-vectorize])
2021-11-18 22:50:13 +03:00
#
# The following tests want to suppress various unhelpful warnings by adding
# -Wno-foo switches. 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. Note that tests of this form typically need to
# be duplicated in the BITCODE_CFLAGS setup stanza below.
#
# Suppress clang's unhelpful unused-command-line-argument warnings.
2018-06-16 22:34:07 +03:00
NOT_THE_CFLAGS=""
2015-04-05 20:01:55 +03: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
2021-11-11 04:51:00 +03:00
# Remove clang 12+'s compound-token-split-by-macro, as this causes a lot
2021-11-18 22:50:13 +03:00
# of warnings when building plperl because of usages in the Perl headers.
2021-11-11 04:51:00 +03:00
NOT_THE_CFLAGS=""
PGAC_PROG_CC_VAR_OPT(NOT_THE_CFLAGS, [-Wcompound-token-split-by-macro])
if test -n "$NOT_THE_CFLAGS"; then
CFLAGS="$CFLAGS -Wno-compound-token-split-by-macro"
fi
2018-06-16 22:34:07 +03: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
2022-12-13 00:03:28 +03:00
# Suppress clang 16's strict warnings about function casts
NOT_THE_CFLAGS=""
PGAC_PROG_CC_VAR_OPT(NOT_THE_CFLAGS, [-Wcast-function-type-strict])
if test -n "$NOT_THE_CFLAGS"; then
CFLAGS="$CFLAGS -Wno-cast-function-type-strict"
fi
2007-08-05 19:43:00 +04: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 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-mp1])
2007-09-12 18:28:55 +04: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 01:41:15 +03:00
PGAC_PROG_CXX_CFLAGS_OPT([-fno-strict-aliasing])
2004-10-20 06:12:07 +04:00
fi
2003-10-25 19:32:11 +04:00
2022-09-10 08:53:02 +03:00
# If the compiler knows how to hide symbols, add the switch needed for that to
# CFLAGS_SL_MODULE and define HAVE_VISIBILITY_ATTRIBUTE.
#
# This is done separately from the above because -fvisibility is supported by
# quite a few different compilers, making the required repetition bothersome.
#
# We might need to add a separate test to check if
# __attribute__((visibility("hidden"))) is supported, if we encounter a
# compiler that supports one of the supported variants of -fvisibility=hidden
# but uses a different syntax to mark a symbol as exported.
if test "$GCC" = yes -o "$SUN_STUDIO_CC" = yes ; then
PGAC_PROG_CC_VAR_OPT(CFLAGS_SL_MODULE, [-fvisibility=hidden])
# For C++ we additionally want -fvisibility-inlines-hidden
PGAC_PROG_VARCXX_VARFLAGS_OPT(CXX, CXXFLAGS_SL_MODULE, [-fvisibility=hidden])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CXX, CXXFLAGS_SL_MODULE, [-fvisibility-inlines-hidden])
have_visibility_attribute=$pgac_cv_prog_CC_cflags__fvisibility_hidden
fi
if test "$have_visibility_attribute" = "yes"; then
AC_DEFINE([HAVE_VISIBILITY_ATTRIBUTE], 1,
[Define to 1 if your compiler knows the visibility("hidden") attribute.])
fi
2020-09-07 04:28:16 +03:00
AC_SUBST(CFLAGS_UNROLL_LOOPS)
AC_SUBST(CFLAGS_VECTORIZE)
Default to hidden visibility for extension libraries where possible
Until now postgres built extension libraries with global visibility, i.e.
exporting all symbols. On the one platform where that behavior is not
natively available, namely windows, we emulate it by analyzing the input files
to the shared library and exporting all the symbols therein.
Not exporting all symbols is actually desirable, as it can improve loading
speed, reduces the likelihood of symbol conflicts and can improve intra
extension library function call performance. It also makes the non-windows
builds more similar to windows builds.
Additionally, with meson implementing the export-all-symbols behavior for
windows, turns out to be more verbose than desirable.
This patch adds support for hiding symbols by default and, to counteract that,
explicit symbol visibility annotation for compilers that support
__attribute__((visibility("default"))) and -fvisibility=hidden. That is
expected to be most, if not all, compilers except msvc (for which we already
support explicit symbol export annotations).
Now that extension library symbols are explicitly exported, we don't need to
export all symbols on windows anymore, hence remove that behavior from
src/tools/msvc. The supporting code can't be removed, as we still need to
export all symbols from the main postgres binary.
Author: Andres Freund <andres@anarazel.de>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20211101020311.av6hphdl6xbjbuif@alap3.anarazel.de
2022-07-18 03:49:51 +03:00
AC_SUBST(CFLAGS_SL_MODULE)
AC_SUBST(CXXFLAGS_SL_MODULE)
2013-04-30 09:59:26 +04:00
2021-11-18 22:50:13 +03:00
# Determine flags used to emit bitcode for JIT inlining.
# 1. We must duplicate any behaviour-changing compiler flags used above,
# to keep compatibility with the compiler used for normal Postgres code.
# 2. We don't bother to duplicate extra-warnings switches --- seeing a
# warning in the main build is enough.
# 3. But we must duplicate -Wno-warning flags, else we'll see those anyway.
2018-03-21 03:26:25 +03:00
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])
2021-11-18 22:50:13 +03:00
2022-10-19 12:18:26 +03:00
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-Xclang -no-opaque-pointers])
PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-Xclang -no-opaque-pointers])
2021-11-18 22:50:13 +03:00
NOT_THE_CFLAGS=""
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, NOT_THE_CFLAGS, [-Wunused-command-line-argument])
if test -n "$NOT_THE_CFLAGS"; then
BITCODE_CFLAGS="$BITCODE_CFLAGS -Wno-unused-command-line-argument"
fi
NOT_THE_CFLAGS=""
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, NOT_THE_CFLAGS, [-Wcompound-token-split-by-macro])
if test -n "$NOT_THE_CFLAGS"; then
BITCODE_CFLAGS="$BITCODE_CFLAGS -Wno-compound-token-split-by-macro"
fi
NOT_THE_CFLAGS=""
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, NOT_THE_CFLAGS, [-Wformat-truncation])
if test -n "$NOT_THE_CFLAGS"; then
BITCODE_CFLAGS="$BITCODE_CFLAGS -Wno-format-truncation"
fi
NOT_THE_CFLAGS=""
PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, NOT_THE_CFLAGS, [-Wstringop-truncation])
if test -n "$NOT_THE_CFLAGS"; then
BITCODE_CFLAGS="$BITCODE_CFLAGS -Wno-stringop-truncation"
fi
2018-03-21 03:26:25 +03:00
fi
2003-10-16 02:23:56 +04:00
# supply -g if --enable-debug
2003-11-01 23:48:51 +03:00
if test "$enable_debug" = yes && test "$ac_cv_prog_cc_g" = yes; then
2003-10-16 02:23:56 +04:00
CFLAGS="$CFLAGS -g"
fi
2003-10-25 19:32:11 +04:00
2018-03-21 01:41:15 +03:00
if test "$enable_debug" = yes && test "$ac_cv_prog_cxx_g" = yes; then
CXXFLAGS="$CXXFLAGS -g"
fi
2008-09-05 16:11:18 +04: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 01:41:15 +03:00
CXXFLAGS="$CXXFLAGS -fprofile-arcs -ftest-coverage"
2008-09-05 16:11:18 +04:00
else
AC_MSG_ERROR([--enable-coverage is supported only when using GCC])
fi
fi
2007-02-21 18:12:39 +03: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-23 23:27:50 +03:00
AC_DEFINE([PROFILE_PID_DIR], 1,
2007-09-21 06:33:46 +04:00
[Define to 1 to allow profiling output to be saved separately for each process.])
CFLAGS="$CFLAGS -pg $PLATFORM_PROFILE_FLAGS"
2018-03-21 01:41:15 +03:00
CXXFLAGS="$CXXFLAGS -pg $PLATFORM_PROFILE_FLAGS"
2007-02-21 18:12:39 +03:00
else
AC_MSG_ERROR([--enable-profiling is supported only when using GCC])
fi
fi
2021-07-15 03:23:47 +03:00
# On Solaris, we need this #define to get POSIX-conforming versions
# of many interfaces (sigwait, getpwuid_r, ...).
if test "$PORTNAME" = "solaris"; then
CPPFLAGS="$CPPFLAGS -D_POSIX_PTHREAD_SEMANTICS"
fi
2003-09-07 07:43:57 +04:00
# We already have this in Makefile.win32, but configure needs it too
2003-10-25 19:32:11 +04:00
if test "$PORTNAME" = "win32"; then
2020-03-25 16:23:25 +03:00
CPPFLAGS="$CPPFLAGS -I$srcdir/src/include/port/win32"
2003-09-07 07:43:57 +04:00
fi
2018-03-21 01:41:15 +03:00
# Now that we're done automatically adding stuff to C[XX]FLAGS, put back the
2015-01-14 19:08:13 +03:00
# user-specified flags (if any) at the end. This lets users override
# the automatic additions.
CFLAGS="$CFLAGS $user_CFLAGS"
2018-03-21 01:41:15 +03:00
CXXFLAGS="$CXXFLAGS $user_CXXFLAGS"
2018-03-21 03:26:25 +03:00
BITCODE_CFLAGS="$BITCODE_CFLAGS $user_BITCODE_CFLAGS"
BITCODE_CXXFLAGS="$BITCODE_CXXFLAGS $user_BITCODE_CXXFLAGS"
2019-10-21 19:32:35 +03: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-14 19:08:13 +03:00
# Check if the compiler still works with the final flag settings
2018-03-21 01:41:15 +03:00
# (note, we're not checking that for CXX, which is optional)
2002-03-29 20:32:55 +03:00
AC_MSG_CHECKING([whether the C compiler still works])
2015-07-02 19:21:23 +03:00
AC_LINK_IFELSE([AC_LANG_PROGRAM([], [return 0;])],
2002-03-29 20:32:55 +03:00
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
AC_MSG_ERROR([cannot proceed])])
2002-09-20 22:38:57 +04:00
2003-10-16 02:23:56 +04:00
# Defend against gcc -ffast-math
2002-09-20 22:38:57 +04:00
if test "$GCC" = yes; then
2015-07-02 19:21:23 +03:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [@%:@ifdef __FAST_MATH__
2002-09-20 22:38:57 +04:00
choke me
2015-07-02 19:21:23 +03:00
@%:@endif])], [], [AC_MSG_ERROR([do not put -ffast-math in CFLAGS])])
2002-09-20 22:38:57 +04: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 00:18:43 +03: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 07:16:34 +04:00
AC_PROG_CPP
2000-06-11 15:40:09 +04:00
AC_SUBST(GCC)
2000-06-10 07:16:34 +04:00
2003-12-23 21:40:53 +03: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)
2022-03-25 10:44:31 +03:00
AC_SUBST(DLSUFFIX)dnl
AC_DEFINE_UNQUOTED([DLSUFFIX], ["$DLSUFFIX"],
[Define to the file name extension of dynamically-loadable modules.])
2020-03-17 19:09:26 +03:00
#
# Set up pkg_config in case we need it below
#
PKG_PROG_PKG_CONFIG
2003-12-23 21:40:53 +03:00
2000-07-16 18:50:44 +04:00
#
# Automatic dependency tracking
#
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(enable, depend, no, [turn on automatic dependency tracking],
2000-09-22 00:17:43 +04:00
[autodepend=yes])
2000-07-16 18:50:44 +04:00
AC_SUBST(autodepend)
2000-09-22 00:17:43 +04:00
#
# Enable assert checks
#
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(enable, cassert, no, [enable assertion checks (for debugging)],
2000-09-22 00:17:43 +04:00
[AC_DEFINE([USE_ASSERT_CHECKING], 1,
2003-04-07 02:45:23 +04:00
[Define to 1 to build with assertion checks. (--enable-cassert)])])
2000-07-15 19:54:52 +04:00
#
# Include directories
#
ac_save_IFS=$IFS
2004-09-02 19:39:56 +04:00
IFS="${IFS}${PATH_SEPARATOR}"
2000-07-15 19:54:52 +04: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 19:39:56 +04:00
IFS="${IFS}${PATH_SEPARATOR}"
2000-07-15 19:54:52 +04: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-25 20:13:52 +04:00
LIBDIRS="$LIBDIRS -L$dir"
2000-07-15 19:54:52 +04:00
else
AC_MSG_WARN([*** Library directory $dir does not exist.])
fi
done
IFS=$ac_save_IFS
2017-03-23 22:25:34 +03:00
#
# ICU
#
AC_MSG_CHECKING([whether to build with ICU support])
2023-04-18 23:20:11 +03:00
PGAC_ARG_BOOL(with, icu, yes, [build without ICU support],
2017-03-23 22:25:34 +03:00
[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
2023-04-18 23:20:11 +03:00
PKG_CHECK_MODULES(ICU, icu-uc icu-i18n, [],
[AC_MSG_ERROR([ICU library not found
If you have ICU already installed, see config.log for details on the
failure. It is possible the compiler isn't looking in the proper directory.
Use --without-icu to disable ICU support.])])
2017-03-23 22:25:34 +03:00
fi
2000-09-26 02:23:01 +04:00
#
2004-10-01 06:00:44 +04:00
# Optionally build Tcl modules (PL/Tcl)
2000-09-26 02:23:01 +04:00
#
AC_MSG_CHECKING([whether to build with Tcl])
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(with, tcl, no, [build Tcl modules (PL/Tcl)])
2000-09-26 02:23:01 +04:00
AC_MSG_RESULT([$with_tcl])
AC_SUBST([with_tcl])
2002-03-29 20:32:55 +03:00
# We see if the path to the Tcl/Tk configuration scripts is specified.
2000-09-22 00:17:43 +04:00
# This will override the use of tclsh to find the paths to search.
1998-10-18 08:16:08 +04:00
2008-10-29 12:27:24 +03:00
PGAC_ARG_REQ(with, tclconfig, [DIR], [tclConfig.sh is in DIR])
2000-09-22 00:17:43 +04:00
2002-08-30 20:23:21 +04:00
#
2002-09-05 02:54:18 +04:00
# Optionally build Perl modules (PL/Perl)
2002-08-30 20:23:21 +04:00
#
AC_MSG_CHECKING([whether to build Perl modules])
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(with, perl, no, [build Perl modules (PL/Perl)])
2002-08-30 20:23:21 +04:00
AC_MSG_RESULT([$with_perl])
AC_SUBST(with_perl)
2000-09-22 00:17:43 +04:00
#
2003-09-02 03:01:49 +04:00
# Optionally build Python modules (PL/Python)
2000-09-22 00:17:43 +04:00
#
AC_MSG_CHECKING([whether to build Python modules])
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(with, python, no, [build Python modules (PL/Python)])
2001-05-12 21:49:32 +04:00
AC_MSG_RESULT([$with_python])
2000-06-10 22:02:12 +04:00
AC_SUBST(with_python)
1998-04-06 00:28:23 +04:00
2007-07-10 17:14:22 +04:00
#
# GSSAPI
#
2007-07-10 20:41:01 +04:00
AC_MSG_CHECKING([whether to build with GSSAPI support])
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(with, gssapi, no, [build with GSSAPI support],
2007-07-10 17:14:22 +04: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-05 22:42:11 +03:00
AC_SUBST(with_gssapi)
2007-07-10 17:14:22 +04:00
2000-07-09 17:14:19 +04:00
2000-08-25 14:00:35 +04:00
AC_SUBST(krb_srvtab)
2000-06-17 04:10:40 +04:00
2000-07-09 17:14:19 +04:00
#
# Kerberos configuration parameters
#
2000-09-22 00:17:43 +04:00
PGAC_ARG_REQ(with, krb-srvnam,
2014-01-15 20:24:01 +04:00
[NAME], [default service principal name in Kerberos (GSSAPI) [postgres]],
2000-09-22 00:17:43 +04:00
[],
[with_krb_srvnam="postgres"])
2018-03-05 22:42:11 +03:00
AC_SUBST(with_krb_srvnam)
2000-09-22 00:17:43 +04:00
AC_DEFINE_UNQUOTED([PG_KRB_SRVNAM], ["$with_krb_srvnam"],
2014-01-15 20:24:01 +04:00
[Define to the name of the default PostgreSQL service principal in Kerberos (GSSAPI). (--with-krb-srvnam=NAME)])
2000-06-17 04:10:40 +04:00
2001-09-06 07:23:38 +04:00
#
# PAM
#
AC_MSG_CHECKING([whether to build with PAM support])
2001-12-14 01:00:22 +03:00
PGAC_ARG_BOOL(with, pam, no,
2008-10-29 12:27:24 +03:00
[build with PAM support],
2003-04-07 02:45:23 +04:00
[AC_DEFINE([USE_PAM], 1, [Define to 1 to build with PAM support. (--with-pam)])])
2001-12-14 01:00:22 +03:00
AC_MSG_RESULT([$with_pam])
2001-09-06 07:23:38 +04:00
2000-06-17 04:10:40 +04:00
2016-04-08 20:51:54 +03: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-06 20:41:44 +03:00
#
# LDAP
#
AC_MSG_CHECKING([whether to build with LDAP support])
PGAC_ARG_BOOL(with, ldap, no,
2008-10-29 12:27:24 +03:00
[build with LDAP support],
2006-03-06 20:41:44 +03:00
[AC_DEFINE([USE_LDAP], 1, [Define to 1 to build with LDAP support. (--with-ldap)])])
AC_MSG_RESULT([$with_ldap])
2018-03-03 09:29:51 +03:00
AC_SUBST(with_ldap)
2006-03-06 20:41:44 +03:00
2003-06-11 10:56:07 +04:00
#
2005-05-15 04:26:19 +04:00
# Bonjour
2003-06-11 10:56:07 +04:00
#
2005-05-15 04:26:19 +04:00
AC_MSG_CHECKING([whether to build with Bonjour support])
PGAC_ARG_BOOL(with, bonjour, no,
2008-10-29 12:27:24 +03:00
[build with Bonjour support],
2005-05-15 04:26:19 +04:00
[AC_DEFINE([USE_BONJOUR], 1, [Define to 1 to build with Bonjour support. (--with-bonjour)])])
AC_MSG_RESULT([$with_bonjour])
2003-06-11 10:56:07 +04:00
2011-01-24 04:44:48 +03: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 17:14:19 +04:00
2015-11-17 14:46:17 +03: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 02:47:09 +04:00
#
# Readline
#
PGAC_ARG_BOOL(with, readline, yes,
2008-10-29 12:27:24 +03:00
[do not use GNU Readline nor BSD Libedit for editing])
2004-07-21 00:37:13 +04: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 17:53:40 +04:00
if test "$PORTNAME" = "win32"; then
2004-07-21 00:37:13 +04:00
if test "$with_readline" = yes; then
AC_MSG_WARN([*** Readline does not work on MinGW --- disabling])
with_readline=no
2004-09-10 17:53:40 +04:00
fi
fi
2020-01-02 23:02:21 +03:00
AC_SUBST(with_readline)
2004-07-21 00:37:13 +04:00
2002-04-11 02:47:09 +04:00
2006-10-02 03:47:16 +04:00
#
# Prefer libedit
#
PGAC_ARG_BOOL(with, libedit-preferred, no,
2008-10-29 12:27:24 +03:00
[prefer BSD Libedit over GNU Readline])
2006-10-02 03:47:16 +04:00
2007-04-21 21:26:18 +04:00
#
2014-05-28 03:42:08 +04:00
# UUID library
2007-04-21 21:26:18 +04:00
#
2014-05-28 03:42:08 +04: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
2021-01-23 05:33:04 +03:00
if test "$with_uuid" != no ; then
if test "$with_uuid" = bsd ; then
AC_DEFINE([HAVE_UUID_BSD], 1, [Define to 1 if you have BSD UUID support.])
elif test "$with_uuid" = e2fs ; then
AC_DEFINE([HAVE_UUID_E2FS], 1, [Define to 1 if you have E2FS UUID support.])
elif test "$with_uuid" = ossp ; then
AC_DEFINE([HAVE_UUID_OSSP], 1, [Define to 1 if you have OSSP UUID support.])
else
AC_MSG_ERROR([--with-uuid must specify one of bsd, e2fs, or ossp])
fi
2014-05-28 03:42:08 +04:00
fi
AC_SUBST(with_uuid)
2007-04-21 21:26:18 +04:00
2006-12-21 19:05:16 +03:00
#
# XML
#
2020-03-17 19:09:26 +03:00
AC_MSG_CHECKING([whether to build with XML support])
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(with, libxml, no, [build with XML support],
2006-12-21 19:05:16 +03:00
[AC_DEFINE([USE_LIBXML], 1, [Define to 1 to build with XML support. (--with-libxml)])])
2020-03-17 19:09:26 +03:00
AC_MSG_RESULT([$with_libxml])
AC_SUBST(with_libxml)
2006-12-21 19:05:16 +03:00
2007-01-18 17:07:31 +03:00
if test "$with_libxml" = yes ; then
2020-03-17 19:09:26 +03:00
# Check pkg-config, then xml2-config. But for backwards compatibility,
# setting XML2_CONFIG overrides pkg-config.
2019-01-18 10:29:42 +03:00
AC_ARG_VAR(XML2_CONFIG, [path to xml2-config utility])dnl
2020-03-17 19:09:26 +03:00
have_libxml2_pkg_config=no
if test -z "$XML2_CONFIG" -a -n "$PKG_CONFIG"; then
PKG_CHECK_MODULES(XML2, [libxml-2.0 >= 2.6.23],
[have_libxml2_pkg_config=yes], [# do nothing])
2007-01-18 17:07:31 +03:00
fi
2020-03-17 19:09:26 +03:00
if test "$have_libxml2_pkg_config" = no ; then
PGAC_PATH_PROGS(XML2_CONFIG, xml2-config)
if test -n "$XML2_CONFIG"; then
XML2_CFLAGS=`$XML2_CONFIG --cflags`
XML2_LIBS=`$XML2_CONFIG --libs`
fi
fi
# Note the user could also set XML2_CFLAGS/XML2_LIBS directly
for pgac_option in $XML2_CFLAGS; do
case $pgac_option in
-I*|-D*) CPPFLAGS="$CPPFLAGS $pgac_option";;
esac
done
for pgac_option in $XML2_LIBS; do
case $pgac_option in
-L*) LDFLAGS="$LDFLAGS $pgac_option";;
esac
done
2007-01-18 17:07:31 +03:00
fi
2006-12-21 19:05:16 +03:00
2007-04-15 16:48:24 +04:00
#
# XSLT
#
2008-10-29 12:27:24 +03:00
PGAC_ARG_BOOL(with, libxslt, no, [use XSLT support when building contrib/xml2],
2008-01-24 09:23:33 +03:00
[AC_DEFINE([USE_LIBXSLT], 1, [Define to 1 to use XSLT support when building contrib/xml2. (--with-libxslt)])])
2007-04-15 16:48:24 +04:00
AC_SUBST(with_libxslt)
2007-08-20 12:53:12 +04:00
#
# tzdata
#
PGAC_ARG_REQ(with, system-tzdata,
2008-10-29 12:27:24 +03:00
[DIR], [use system time zone data in DIR])
2007-08-20 12:53:12 +04:00
AC_SUBST(with_system_tzdata)
2002-04-11 02:47:09 +04:00
#
# Zlib
#
PGAC_ARG_BOOL(with, zlib, yes,
2008-10-29 12:27:24 +03:00
[do not use Zlib])
2005-07-06 03:13:57 +04:00
AC_SUBST(with_zlib)
2002-04-11 02:47:09 +04:00
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 22:10:38 +03:00
#
# LZ4
#
AC_MSG_CHECKING([whether to build with LZ4 support])
PGAC_ARG_BOOL(with, lz4, no, [build with LZ4 support],
[AC_DEFINE([USE_LZ4], 1, [Define to 1 to build with LZ4 support. (--with-lz4)])])
AC_MSG_RESULT([$with_lz4])
AC_SUBST(with_lz4)
if test "$with_lz4" = yes; then
PKG_CHECK_MODULES(LZ4, liblz4)
2021-03-22 00:20:17 +03:00
# We only care about -I, -D, and -L switches;
# note that -llz4 will be added by AC_CHECK_LIB below.
for pgac_option in $LZ4_CFLAGS; do
case $pgac_option in
-I*|-D*) CPPFLAGS="$CPPFLAGS $pgac_option";;
esac
done
for pgac_option in $LZ4_LIBS; do
case $pgac_option in
-L*) LDFLAGS="$LDFLAGS $pgac_option";;
esac
done
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 22:10:38 +03:00
fi
2022-02-18 21:40:31 +03:00
#
# ZSTD
#
AC_MSG_CHECKING([whether to build with ZSTD support])
PGAC_ARG_BOOL(with, zstd, no, [build with ZSTD support],
[AC_DEFINE([USE_ZSTD], 1, [Define to 1 to build with ZSTD support. (--with-zstd)])])
AC_MSG_RESULT([$with_zstd])
AC_SUBST(with_zstd)
if test "$with_zstd" = yes; then
2022-04-01 18:05:52 +03:00
PKG_CHECK_MODULES(ZSTD, libzstd >= 1.4.0)
2022-02-18 21:40:31 +03:00
# We only care about -I, -D, and -L switches;
# note that -lzstd will be added by AC_CHECK_LIB below.
for pgac_option in $ZSTD_CFLAGS; do
case $pgac_option in
-I*|-D*) CPPFLAGS="$CPPFLAGS $pgac_option";;
esac
done
for pgac_option in $ZSTD_LIBS; do
case $pgac_option in
-L*) LDFLAGS="$LDFLAGS $pgac_option";;
esac
done
fi
2003-05-27 20:36:50 +04:00
#
# Assignments
#
2000-03-30 09:29:21 +04:00
2000-07-15 19:54:52 +04:00
CPPFLAGS="$CPPFLAGS $INCLUDES"
2000-10-25 20:13:52 +04:00
LDFLAGS="$LDFLAGS $LIBDIRS"
2000-07-15 19:54:52 +04:00
2010-07-05 22:54:38 +04: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 19:54:52 +04:00
2002-04-10 20:45:25 +04:00
PGAC_CHECK_STRIP
2008-12-07 11:36:22 +03:00
AC_CHECK_TOOL(AR, ar, ar)
if test "$PORTNAME" = "win32"; then
AC_CHECK_TOOL(WINDRES, windres, windres)
fi
2001-02-11 01:31:42 +03:00
2012-06-27 14:40:51 +04:00
AC_PROG_INSTALL
# When Autoconf chooses install-sh as install program it tries to generate
2017-02-06 12:33:58 +03:00
# a relative path to it in each makefile where it substitutes it. This clashes
2012-06-27 14:40:51 +04:00
# with our Makefile.global concept. This workaround helps.
case $INSTALL in
2012-06-28 21:05:36 +04:00
*install-sh*) install_bin='';;
*) install_bin=$INSTALL;;
2012-06-27 14:40:51 +04:00
esac
2012-06-28 21:05:36 +04:00
AC_SUBST(install_bin)
2012-06-27 14:40:51 +04: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 18:40:00 +03:00
PGAC_PATH_PROGS(TAR, tar)
2007-07-19 21:15:30 +04:00
AC_PROG_LN_S
2009-08-27 02:24:44 +04:00
AC_PROG_MKDIR_P
# When Autoconf chooses install-sh as mkdir -p program it tries to generate
2017-02-06 12:33:58 +03:00
# a relative path to it in each makefile where it substitutes it. This clashes
2009-08-27 02:24:44 +04: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-06 23:11:55 +04:00
2008-08-29 17:02:33 +04:00
PGAC_PATH_BISON
2007-07-19 21:15:30 +04:00
PGAC_PATH_FLEX
2001-02-11 01:31:42 +03:00
2002-08-30 20:23:21 +04:00
PGAC_PATH_PERL
if test "$with_perl" = yes; then
2010-01-07 06:24:57 +03:00
if test -z "$PERL"; then
AC_MSG_ERROR([Perl not found])
fi
2002-09-05 02:54:18 +04: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 04:38:21 +03: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-25 20:23:29 +03: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-18 21:55:23 +03: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-16 23:27:15 +03: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-18 21:55:23 +03:00
perl_includespec="-iwithsysroot $perl_archlibexp/CORE"
2018-09-25 20:23:29 +03: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-18 21:55:23 +03: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-28 21:25:28 +03:00
PGAC_CHECK_PERL_EMBED_CCFLAGS
2002-08-30 20:23:21 +04:00
PGAC_CHECK_PERL_EMBED_LDFLAGS
fi
2001-05-12 21:49:32 +04:00
if test "$with_python" = yes; then
PGAC_PATH_PYTHON
PGAC_CHECK_PYTHON_EMBED_SETUP
fi
2021-12-01 01:18:04 +03:00
if test x"$cross_compiling" = x"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 18:40:00 +03:00
PGAC_PATH_PROGS(ZIC, zic)
2009-01-05 13:25:59 +03: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 00:05:45 +03: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.
# 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 17:55:17 +03: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.
2023-07-11 21:20:37 +03:00
AS_IF([test "$PORTNAME" != "win32"],
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 11:38:34 +03:00
[ # then
2015-07-09 00:05:45 +03:00
AX_PTHREAD # set thread flags
# Some platforms use these, so just define them. They can't hurt if they
2021-07-15 03:23:47 +03:00
# are not supported.
PTHREAD_CFLAGS="$PTHREAD_CFLAGS -D_REENTRANT -D_THREAD_SAFE"
2015-07-09 00:05:45 +03:00
# Check for *_r functions
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
LIBS="$LIBS $PTHREAD_LIBS"
AC_CHECK_HEADER(pthread.h, [], [AC_MSG_ERROR([
2023-07-11 21:20:37 +03:00
pthread.h not found])])
2015-07-09 00:05:45 +03:00
2022-08-14 00:57:48 +03:00
AC_CHECK_FUNCS([strerror_r])
2015-07-09 00:05:45 +03: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 11:38:34 +03:00
], [ # else
2015-07-09 00:05:45 +03: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 11:38:34 +03:00
]) # fi
2015-07-09 00:05:45 +03:00
AC_SUBST(PTHREAD_CFLAGS)
AC_SUBST(PTHREAD_LIBS)
2000-06-07 20:27:00 +04:00
2002-04-26 23:47:35 +04:00
##
2000-07-13 02:59:15 +04:00
## Libraries
##
2006-11-06 06:44:38 +03: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 02:59:15 +04:00
2006-11-06 06:44:38 +03:00
AC_CHECK_LIB(m, main)
2006-02-04 03:42:54 +03:00
AC_SEARCH_LIBS(setproctitle, util)
2022-03-23 22:43:14 +03:00
# gcc/clang's sanitizer helper library provides dlopen but not dlsym, thus
# when enabling asan the dlopen check doesn't notice that -ldl is actually
# required. Just checking for dlsym() ought to suffice.
AC_SEARCH_LIBS(dlsym, dl)
2014-07-15 16:18:39 +04:00
AC_SEARCH_LIBS(socket, [socket ws2_32])
2002-09-17 08:27:41 +04:00
AC_SEARCH_LIBS(getopt_long, [getopt gnugetopt])
2013-10-10 05:05:02 +04:00
AC_SEARCH_LIBS(shm_open, rt)
AC_SEARCH_LIBS(shm_unlink, rt)
2023-08-17 07:16:43 +03:00
AC_SEARCH_LIBS(clock_gettime, rt)
2002-09-05 22:28:46 +04:00
# Cygwin:
2006-02-04 03:42:54 +03:00
AC_SEARCH_LIBS(shmget, cygipc)
2019-11-08 21:44:20 +03:00
# *BSD:
AC_SEARCH_LIBS(backtrace_symbols, execinfo)
2000-07-09 17:14:19 +04:00
2023-07-11 21:20:37 +03:00
AC_SEARCH_LIBS(pthread_barrier_wait, pthread)
2021-03-13 07:21:01 +03:00
2002-04-11 02:47:09 +04: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 08:27:48 +04: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 02:47:09 +04: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 08:27:48 +04: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 02:47:09 +04:00
Use --without-zlib to disable zlib support.])])
fi
2003-09-13 21:01:09 +04:00
if test "$enable_spinlocks" = yes; then
2003-09-12 20:10:27 +04: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 01:49:05 +04: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 17:14:22 +04:00
if test "$with_gssapi" = yes ; then
if test "$PORTNAME" != "win32"; then
2023-04-17 16:51:04 +03:00
AC_SEARCH_LIBS(gss_store_cred_into, [gssapi_krb5 gss 'gssapi -lkrb5 -lcrypto'], [],
[AC_MSG_ERROR([could not find function 'gss_store_cred_into' required for GSSAPI])])
2007-07-10 17:14:22 +04:00
else
LIBS="$LIBS -lgssapi32"
fi
fi
2021-02-01 13:19:44 +03:00
#
# SSL Library
#
# There is currently only one supported SSL/TLS library: OpenSSL.
#
PGAC_ARG_REQ(with, ssl, [LIB], [use LIB for SSL/TLS support (openssl)])
if test x"$with_ssl" = x"" ; then
with_ssl=no
fi
PGAC_ARG_BOOL(with, openssl, no, [obsolete spelling of --with-ssl=openssl])
2000-07-09 17:14:19 +04:00
if test "$with_openssl" = yes ; then
2021-02-01 13:19:44 +03:00
with_ssl=openssl
fi
if test "$with_ssl" = openssl ; then
2000-07-09 17:14:19 +04:00
dnl Order matters!
2023-07-03 07:20:27 +03:00
# Minimum required OpenSSL version is 1.0.2
AC_DEFINE(OPENSSL_API_COMPAT, [0x10002000L],
2020-07-19 13:14:42 +03:00
[Define to the OpenSSL API version in use. This avoids deprecation warnings from newer OpenSSL versions.])
2004-10-06 13:35:23 +04: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 12:36:21 +03:00
AC_CHECK_LIB(ssl, SSL_new, [], [AC_MSG_ERROR([library 'ssl' is required for OpenSSL])])
2004-10-06 13:35:23 +04:00
else
2017-11-09 01:47:14 +03: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 13:35:23 +04:00
fi
2023-07-07 07:59:41 +03:00
# Function introduced in OpenSSL 1.0.2, not in LibreSSL.
2023-07-03 07:20:27 +03:00
AC_CHECK_FUNCS([SSL_CTX_set_cert_cb])
2016-09-15 22:29:39 +03: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.
Use BIO_{get,set}_app_data instead of BIO_{get,set}_data.
We should have done it this way all along, but we accidentally got
away with using the wrong BIO field up until OpenSSL 3.2. There,
the library's BIO routines that we rely on use the "data" field
for their own purposes, and our conflicting use causes assorted
weird behaviors up to and including core dumps when SSL connections
are attempted. Switch to using the approved field for the purpose,
i.e. app_data.
While at it, remove our configure probes for BIO_get_data as well
as the fallback implementation. BIO_{get,set}_app_data have been
there since long before any OpenSSL version that we still support,
even in the back branches.
Also, update src/test/ssl/t/001_ssltests.pl to allow for a minor
change in an error message spelling that evidently came in with 3.2.
Tristan Partin and Bo Andreson. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAN55FZ1eDDYsYaL7mv+oSLUij2h_u6hvD4Qmv-7PK7jkji0uyQ@mail.gmail.com
2023-11-28 20:34:03 +03:00
AC_CHECK_FUNCS([OPENSSL_init_ssl BIO_meth_new ASN1_STRING_get0_data HMAC_CTX_new HMAC_CTX_free])
2016-09-15 22:29:39 +03: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])
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
2023-02-15 04:12:16 +03:00
# Function introduced in OpenSSL 1.1.1.
AC_CHECK_FUNCS([X509_get_signature_info])
2021-02-20 04:17:10 +03:00
AC_DEFINE([USE_OPENSSL], 1, [Define to 1 to build with OpenSSL support. (--with-ssl=openssl)])
2021-02-01 13:19:44 +03:00
elif test "$with_ssl" != no ; then
AC_MSG_ERROR([--with-ssl must specify openssl])
2000-07-09 17:14:19 +04:00
fi
2021-02-01 13:19:44 +03:00
AC_SUBST(with_ssl)
1997-02-04 11:53:45 +03:00
2001-09-06 07:23:38 +04:00
if test "$with_pam" = yes ; then
2002-12-29 06:56:35 +03:00
AC_CHECK_LIB(pam, pam_start, [], [AC_MSG_ERROR([library 'pam' is required for PAM])])
2001-09-06 07:23:38 +04:00
fi
2006-12-21 19:05:16 +03:00
if test "$with_libxml" = yes ; then
2007-01-08 00:10:41 +03:00
AC_CHECK_LIB(xml2, xmlSaveToBuffer, [], [AC_MSG_ERROR([library 'xml2' (version >= 2.6.23) is required for XML support])])
2006-12-21 19:05:16 +03:00
fi
2007-04-15 16:48:24 +04:00
if test "$with_libxslt" = yes ; then
2008-04-29 02:47:03 +04:00
AC_CHECK_LIB(xslt, xsltCleanupGlobals, [], [AC_MSG_ERROR([library 'xslt' is required for XSLT support])])
2007-04-15 16:48:24 +04:00
fi
2021-03-22 00:20:17 +03:00
if test "$with_lz4" = yes ; then
AC_CHECK_LIB(lz4, LZ4_compress_default, [], [AC_MSG_ERROR([library 'lz4' is required for LZ4 support])])
fi
2022-02-18 21:40:31 +03:00
if test "$with_zstd" = yes ; then
AC_CHECK_LIB(zstd, ZSTD_compress, [], [AC_MSG_ERROR([library 'zstd' is required for ZSTD support])])
fi
Remove AIX support
There isn't a lot of user demand for AIX support, we have a bunch of
hacks to work around AIX-specific compiler bugs and idiosyncrasies,
and no one has stepped up to the plate to properly maintain it.
Remove support for AIX to get rid of that maintenance overhead. It's
still supported for stable versions.
The acute issue that triggered this decision was that after commit
8af2565248, the AIX buildfarm members have been hitting this
assertion:
TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer)"), File: "md.c", Line: 472, PID: 2949728
Apperently the "pg_attribute_aligned(a)" attribute doesn't work on AIX
for values larger than PG_IO_ALIGN_SIZE, for a static const variable.
That could be worked around, but we decided to just drop the AIX support
instead.
Discussion: https://www.postgresql.org/message-id/20240224172345.32@rfd.leadboat.com
Reviewed-by: Andres Freund, Noah Misch, Thomas Munro
2024-02-28 14:10:51 +03:00
# Note: We can test for libldap_r only after we know PTHREAD_LIBS
2015-07-09 00:05:45 +03:00
if test "$with_ldap" = yes ; then
_LIBS="$LIBS"
if test "$PORTNAME" != "win32"; then
2021-07-09 23:59:07 +03:00
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"
2021-07-10 20:19:30 +03:00
# This test is carried out against libldap.
AC_CHECK_FUNCS([ldap_initialize])
2022-05-11 01:42:02 +03:00
# The separate ldap_r library only exists in OpenLDAP < 2.5, and if we
# have 2.5 or later, we shouldn't even probe for ldap_r (we might find a
# library from a separate OpenLDAP installation). The most reliable
# way to check that is to check for a function introduced in 2.5.
AC_CHECK_FUNC([ldap_verify_credentials],
[thread_safe_libldap=yes],
[thread_safe_libldap=no])
2023-07-11 21:20:37 +03:00
if test "$thread_safe_libldap" = no; then
2021-07-09 19:38:55 +03:00
# Use ldap_r for FE if available, else assume ldap is thread-safe.
2021-07-09 23:59:07 +03:00
# On some platforms ldap_r fails to link without PTHREAD_LIBS.
LIBS="$_LIBS"
AC_CHECK_LIB(ldap_r, ldap_bind,
[LDAP_LIBS_FE="-lldap_r $EXTRA_LDAP_LIBS"],
[LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS"],
[$PTHREAD_CFLAGS $PTHREAD_LIBS $EXTRA_LDAP_LIBS])
2015-07-09 00:05:45 +03:00
else
LDAP_LIBS_FE="-lldap $EXTRA_LDAP_LIBS"
fi
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 04:44:48 +03:00
# for contrib/sepgsql
if test "$with_selinux" = yes; then
2013-03-28 23:38:35 +04: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 04:44:48 +03:00
fi
2007-11-13 03:13:19 +03:00
# for contrib/uuid-ossp
2014-05-28 03:42:08 +04: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-25 22:40:57 +03:00
# On macOS, the UUID functions are in libc
2014-05-28 03:42:08 +04: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 03:13:19 +03:00
AC_CHECK_LIB(ossp-uuid, uuid_export,
2014-05-28 03:42:08 +04:00
[UUID_LIBS="-lossp-uuid"],
2007-11-13 03:13:19 +03:00
[AC_CHECK_LIB(uuid, uuid_export,
2014-05-28 03:42:08 +04:00
[UUID_LIBS="-luuid"],
[AC_MSG_ERROR([library 'ossp-uuid' or 'uuid' is required for OSSP UUID])])])
2007-11-13 03:13:19 +03:00
fi
2014-05-28 03:42:08 +04:00
AC_SUBST(UUID_LIBS)
2007-11-13 03:13:19 +03:00
2002-03-29 20:32:55 +03:00
2000-07-13 02:59:15 +04:00
##
## Header files
##
2002-07-28 00:10:05 +04:00
2018-03-21 14:43:29 +03:00
AC_HEADER_STDBOOL
2018-10-09 07:04:27 +03:00
AC_CHECK_HEADERS(m4_normalize([
atomic.h
2018-11-08 00:41:42 +03:00
copyfile.h
2019-11-08 21:44:20 +03:00
execinfo.h
2018-10-09 07:04:27 +03:00
getopt.h
ifaddrs.h
langinfo.h
mbarrier.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 07:35:57 +03:00
sys/event.h
2022-01-10 13:54:11 +03:00
sys/personality.h
2018-10-09 07:04:27 +03:00
sys/prctl.h
sys/procctl.h
2022-02-09 22:24:54 +03:00
sys/signalfd.h
2022-08-07 19:36:01 +03:00
sys/ucred.h
2018-10-09 07:04:27 +03:00
termios.h
ucred.h
]))
2009-10-01 05:58:58 +04:00
2004-11-30 09:13:04 +03:00
if expr x"$pgac_cv_check_readline" : 'x-lreadline' >/dev/null ; then
2002-12-29 06:56:35 +03:00
AC_CHECK_HEADERS(readline/readline.h, [],
2004-12-03 00:41:12 +03:00
[AC_CHECK_HEADERS(readline.h, [],
[AC_MSG_ERROR([readline header not found
2002-09-11 08:27:48 +04: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 09:13:04 +03:00
Use --without-readline to disable readline support.])])])
2002-12-29 06:56:35 +03:00
AC_CHECK_HEADERS(readline/history.h, [],
2004-12-03 00:41:12 +03:00
[AC_CHECK_HEADERS(history.h, [],
[AC_MSG_ERROR([history header not found
2002-09-11 08:27:48 +04: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 09:13:04 +03:00
Use --without-readline to disable readline support.])])])
fi
if expr x"$pgac_cv_check_readline" : 'x-ledit' >/dev/null ; then
2004-12-03 00:41:12 +03: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 09:13:04 +03:00
AC_CHECK_HEADERS(editline/readline.h, [],
2004-12-03 00:41:12 +03:00
[AC_CHECK_HEADERS(readline.h, [],
[AC_CHECK_HEADERS(readline/readline.h, [],
[AC_MSG_ERROR([readline header not found
2004-11-30 09:13:04 +03: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 00:41:12 +03:00
Use --without-readline to disable libedit support.])])])])
2006-10-05 04:07:45 +04: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 02:47:09 +04:00
fi
if test "$with_zlib" = yes; then
AC_CHECK_HEADER(zlib.h, [], [AC_MSG_ERROR([zlib header not found
2003-01-11 07:58:44 +03:00
If you have zlib already installed, see config.log for details on the
2002-09-11 08:27:48 +04:00
failure. It is possible the compiler isn't looking in the proper directory.
2002-04-11 02:47:09 +04:00
Use --without-zlib to disable zlib support.])])
fi
2000-06-19 20:58:48 +04:00
2022-02-14 04:40:34 +03:00
PGAC_PATH_PROGS(LZ4, lz4)
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 22:10:38 +03:00
if test "$with_lz4" = yes; then
2022-05-04 14:33:59 +03:00
AC_CHECK_HEADER(lz4.h, [], [AC_MSG_ERROR([lz4.h header file is required for LZ4])])
Allow configurable LZ4 TOAST compression.
There is now a per-column COMPRESSION option which can be set to pglz
(the default, and the only option in up until now) or lz4. Or, if you
like, you can set the new default_toast_compression GUC to lz4, and
then that will be the default for new table columns for which no value
is specified. We don't have lz4 support in the PostgreSQL code, so
to use lz4 compression, PostgreSQL must be built --with-lz4.
In general, TOAST compression means compression of individual column
values, not the whole tuple, and those values can either be compressed
inline within the tuple or compressed and then stored externally in
the TOAST table, so those properties also apply to this feature.
Prior to this commit, a TOAST pointer has two unused bits as part of
the va_extsize field, and a compessed datum has two unused bits as
part of the va_rawsize field. These bits are unused because the length
of a varlena is limited to 1GB; we now use them to indicate the
compression type that was used. This means we only have bit space for
2 more built-in compresison types, but we could work around that
problem, if necessary, by introducing a new vartag_external value for
any further types we end up wanting to add. Hopefully, it won't be
too important to offer a wide selection of algorithms here, since
each one we add not only takes more coding but also adds a build
dependency for every packager. Nevertheless, it seems worth doing
at least this much, because LZ4 gets better compression than PGLZ
with less CPU usage.
It's possible for LZ4-compressed datums to leak into composite type
values stored on disk, just as it is for PGLZ. It's also possible for
LZ4-compressed attributes to be copied into a different table via SQL
commands such as CREATE TABLE AS or INSERT .. SELECT. It would be
expensive to force such values to be decompressed, so PostgreSQL has
never done so. For the same reasons, we also don't force recompression
of already-compressed values even if the target table prefers a
different compression method than was used for the source data. These
architectural decisions are perhaps arguable but revisiting them is
well beyond the scope of what seemed possible to do as part of this
project. However, it's relatively cheap to recompress as part of
VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
so, if the configured compression method of the table happens not to
match what was used for some column value stored therein.
Dilip Kumar. The original patches on which this work was based were
written by Ildus Kurbangaliev, and those were patches were based on
even earlier work by Nikita Glukhov, but the design has since changed
very substantially, since allow a potentially large number of
compression methods that could be added and dropped on a running
system proved too problematic given some of the architectural issues
mentioned above; the choice of which specific compression method to
add first is now different; and a lot of the code has been heavily
refactored. More recently, Justin Przyby helped quite a bit with
testing and reviewing and this version also includes some code
contributions from him. Other design input and review from Tomas
Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
Korotkov, and me.
Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
2021-03-19 22:10:38 +03:00
fi
2022-02-18 21:40:31 +03:00
PGAC_PATH_PROGS(ZSTD, zstd)
if test "$with_zstd" = yes; then
AC_CHECK_HEADER(zstd.h, [], [AC_MSG_ERROR([zstd.h header file is required for ZSTD])])
fi
2007-07-10 17:14:22 +04:00
if test "$with_gssapi" = yes ; then
2007-07-12 18:36:52 +04:00
AC_CHECK_HEADERS(gssapi/gssapi.h, [],
[AC_CHECK_HEADERS(gssapi.h, [], [AC_MSG_ERROR([gssapi.h header file is required for GSSAPI])])])
2023-04-13 15:55:13 +03:00
AC_CHECK_HEADERS(gssapi/gssapi_ext.h, [],
[AC_CHECK_HEADERS(gssapi_ext.h, [], [AC_MSG_ERROR([gssapi_ext.h header file is required for GSSAPI])])])
2007-07-10 17:14:22 +04:00
fi
2022-10-20 22:01:05 +03:00
PGAC_PATH_PROGS(OPENSSL, openssl)
2023-10-25 03:26:22 +03:00
pgac_openssl_version="$($OPENSSL version 2> /dev/null || echo openssl not found)"
AC_MSG_NOTICE([using openssl: $pgac_openssl_version])
2021-02-01 13:19:44 +03:00
if test "$with_ssl" = openssl ; then
2002-12-29 06:56:35 +03: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 17:14:19 +04:00
fi
2001-09-06 07:23:38 +04:00
if test "$with_pam" = yes ; then
2003-02-14 17:05:00 +03: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 07:23:38 +04:00
fi
2016-04-08 20:51:54 +03: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 14:46:17 +03: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-21 19:05:16 +03: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 16:48:24 +04: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-06 20:41:44 +03:00
if test "$with_ldap" = yes ; then
if test "$PORTNAME" != "win32"; then
2022-08-18 20:41:42 +03:00
AC_CHECK_HEADER(ldap.h, [],
[AC_MSG_ERROR([header file <ldap.h> is required for LDAP])])
2014-07-22 19:01:03 +04:00
PGAC_LDAP_SAFE
2006-03-06 20:41:44 +03:00
else
2022-08-18 20:41:42 +03:00
AC_CHECK_HEADER(winldap.h, [],
[AC_MSG_ERROR([header file <winldap.h> is required for LDAP])],
[AC_INCLUDES_DEFAULT
2006-03-06 20:41:44 +03:00
#include <windows.h>
2022-08-18 20:41:42 +03:00
])
2006-03-06 20:41:44 +03:00
fi
fi
2005-05-15 04:26:19 +04:00
if test "$with_bonjour" = yes ; then
2009-09-08 20:08:26 +04:00
AC_CHECK_HEADER(dns_sd.h, [], [AC_MSG_ERROR([header file <dns_sd.h> is required for Bonjour])])
2017-11-09 19:00:36 +03: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 10:56:07 +04:00
fi
2007-10-24 01:38:16 +04:00
# for contrib/uuid-ossp
2014-05-28 03:42:08 +04: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 01:38:16 +04:00
fi
2011-12-11 00:35:41 +04:00
if test "$PORTNAME" = "win32" ; then
AC_CHECK_HEADERS(crtdefs.h)
fi
1997-02-04 11:53:45 +03:00
2000-07-13 02:59:15 +04:00
##
## Types, structures, compiler characteristics
##
2002-07-28 00:10:05 +04:00
2002-03-29 20:32:55 +03:00
m4_defun([AC_PROG_CC_STDC], []) dnl We don't want that.
2007-04-06 08:21:44 +04:00
AC_C_BIGENDIAN
2015-08-05 19:19:52 +03:00
AC_C_INLINE
2014-11-23 17:34:03 +03:00
PGAC_PRINTF_ARCHETYPE
2012-09-30 22:38:31 +04:00
PGAC_C_STATIC_ASSERT
2017-03-09 23:18:59 +03:00
PGAC_C_TYPEOF
2012-09-30 22:38:31 +04: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 03:39:20 +04:00
PGAC_C_BUILTIN_CONSTANT_P
PGAC_C_BUILTIN_UNREACHABLE
2017-03-20 20:35:21 +03:00
PGAC_C_COMPUTED_GOTO
2003-05-22 20:39:30 +04:00
PGAC_STRUCT_TIMEZONE
2000-07-13 02:59:15 +04:00
PGAC_UNION_SEMUN
2021-11-09 17:20:47 +03:00
AC_CHECK_TYPES(socklen_t, [], [], [#include <sys/socket.h>])
2022-08-22 07:47:17 +03:00
PGAC_STRUCT_SOCKADDR_SA_LEN
1997-02-06 08:30:50 +03:00
2011-02-09 00:04:18 +03:00
PGAC_TYPE_LOCALE_T
2017-10-13 01:25:38 +03: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.
AC_C_RESTRICT
Remove AIX support
There isn't a lot of user demand for AIX support, we have a bunch of
hacks to work around AIX-specific compiler bugs and idiosyncrasies,
and no one has stepped up to the plate to properly maintain it.
Remove support for AIX to get rid of that maintenance overhead. It's
still supported for stable versions.
The acute issue that triggered this decision was that after commit
8af2565248, the AIX buildfarm members have been hitting this
assertion:
TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer)"), File: "md.c", Line: 472, PID: 2949728
Apperently the "pg_attribute_aligned(a)" attribute doesn't work on AIX
for values larger than PG_IO_ALIGN_SIZE, for a static const variable.
That could be worked around, but we decided to just drop the AIX support
instead.
Discussion: https://www.postgresql.org/message-id/20240224172345.32@rfd.leadboat.com
Reviewed-by: Andres Freund, Noah Misch, Thomas Munro
2024-02-28 14:10:51 +03:00
if test "$ac_cv_c_restrict" = "no"; then
2017-10-13 01:25:38 +03: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])
2003-08-08 01:11:58 +04:00
AC_CHECK_TYPES([struct option], [], [],
[#ifdef HAVE_GETOPT_H
2003-08-08 01:38:55 +04:00
#include <getopt.h>
2003-08-08 01:11:58 +04:00
#endif])
2012-01-02 07:39:59 +04: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 07:22:27 +03: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 07:39:59 +04:00
ppc*|powerpc*)
2022-08-13 20:36:39 +03:00
# On PPC, check if compiler accepts "i"(x) when __builtin_constant_p(x).
2019-10-19 06:20:52 +03:00
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 07:39:59 +04:00
;;
esac
2010-01-16 22:50:26 +03: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 00:35:41 +04:00
if test "$PORTNAME" != "win32"; then
AC_SYS_LARGEFILE
2014-02-23 05:42:39 +04: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-25 22:40:57 +03: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 05:42:39 +04:00
dnl versions where the feature actually works, it's on by default anyway.
2013-12-29 21:57:45 +04:00
AH_VERBATIM([_DARWIN_USE_64_BIT_INODE],[])
2011-12-11 00:35:41 +04:00
fi
2010-01-16 22:50:26 +03:00
2019-02-09 17:55:17 +03:00
dnl Check for largefile support (must be after AC_SYS_LARGEFILE)
2010-01-16 22:50:26 +03:00
AC_CHECK_SIZEOF([off_t])
2022-12-08 06:32:59 +03:00
# If we don't have largefile support, can't handle segment size >= 2GB.
if test "$ac_cv_sizeof_off_t" -lt 8; then
if expr $RELSEG_SIZE '*' $blocksize '>=' 2 '*' 1024 '*' 1024; then
AC_MSG_ERROR([Large file support is not enabled. Segment size cannot be larger than 1GB.])
fi
2010-01-16 22:50:26 +03:00
fi
2018-03-21 14:43:29 +03: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-12 21:00:04 +03: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 02:52:31 +03:00
2000-07-13 02:59:15 +04:00
##
## Functions, global variables
##
2002-07-28 00:10:05 +04:00
2000-06-11 15:40:09 +04:00
PGAC_VAR_INT_TIMEZONE
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-15 20:19:57 +03:00
PGAC_FUNC_WCSTOMBS_L
1997-02-04 11:53:45 +03:00
2012-12-19 01:22:13 +04: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 07:04:27 +03:00
AC_CHECK_FUNCS(m4_normalize([
2019-11-08 21:44:20 +03:00
backtrace_symbols
2018-11-07 20:05:54 +03:00
copyfile
2024-03-06 01:39:50 +03:00
copy_file_range
2018-10-09 07:04:27 +03:00
getifaddrs
getpeerucred
2022-04-01 16:41:44 +03:00
inet_pton
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 07:35:57 +03:00
kqueue
2018-10-09 07:04:27 +03:00
mbstowcs_l
2019-09-05 09:15:58 +03:00
memset_s
2018-10-09 07:04:27 +03:00
posix_fallocate
ppoll
pthread_is_threaded_np
setproctitle
setproctitle_fast
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 03:38:57 +03:00
strsignal
2021-03-20 01:46:32 +03:00
syncfs
2018-10-09 07:04:27 +03:00
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-21 20:07:02 +03:00
uselocale
2018-10-09 07:04:27 +03:00
wcstombs_l
]))
2001-02-18 07:39:42 +03: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 07:22:27 +03: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])
2022-02-18 06:45:34 +03:00
# __builtin_frame_address may draw a diagnostic for non-constant argument,
# so it needs a different test function.
PGAC_CHECK_BUILTIN_FUNC_PTR([__builtin_frame_address], [0])
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 07:22:27 +03:00
2020-02-21 20:49:42 +03: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-16 22:50:26 +03:00
2009-04-08 02:48:30 +04: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-19 20:01:47 +03:00
dnl must use AS_IF here, else AC_REQUIRES inside AC_CHECK_DECLS malfunctions
AS_IF([test "$PORTNAME" != "solaris"], [
2009-04-08 02:48:30 +04:00
AC_CHECK_FUNCS(posix_fadvise)
2006-06-18 22:30:21 +04:00
AC_CHECK_DECLS(posix_fadvise, [], [], [#include <fcntl.h>])
2018-11-19 20:01:47 +03:00
]) # fi
2009-04-08 02:48:30 +04:00
AC_CHECK_DECLS(fdatasync, [], [], [#include <unistd.h>])
2024-07-22 10:47:02 +03:00
AC_CHECK_DECLS([strlcat, strlcpy, strnlen, strsep])
2021-07-13 02:17:35 +03:00
2023-11-29 06:44:19 +03:00
# We can't use AC_CHECK_FUNCS to detect these functions, because it
2021-07-13 02:17:35 +03:00
# won't handle deployment target restrictions on macOS
2023-11-29 06:44:19 +03:00
AC_CHECK_DECLS([preadv], [], [], [#include <sys/uio.h>])
AC_CHECK_DECLS([pwritev], [], [], [#include <sys/uio.h>])
2021-07-13 02:17:35 +03:00
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-25 22:40:57 +03:00
# This is probably only present on macOS, but may as well check always
2006-10-02 04:06:18 +04:00
AC_CHECK_DECLS(F_FULLFSYNC, [], [], [#include <fcntl.h>])
2000-05-24 18:58:21 +04:00
2018-10-09 07:04:27 +03:00
AC_REPLACE_FUNCS(m4_normalize([
2019-09-05 09:15:58 +03:00
explicit_bzero
2018-10-09 07:04:27 +03:00
getopt
2019-10-30 14:58:32 +03:00
getpeereid
2018-10-09 07:04:27 +03:00
inet_aton
mkdtemp
strlcat
strlcpy
strnlen
2024-07-22 10:47:02 +03:00
strsep
2018-10-09 07:04:27 +03:00
]))
2009-02-12 18:12:47 +03:00
2023-07-11 21:20:37 +03:00
AC_REPLACE_FUNCS(pthread_barrier_wait)
2021-03-13 07:21:01 +03:00
2019-12-19 10:28:37 +03:00
if test "$PORTNAME" = "win32" -o "$PORTNAME" = "cygwin"; then
2019-02-16 04:50:16 +03:00
# Cygwin and (apparently, based on test results) Mingw both
2022-07-14 05:22:49 +03:00
# have a broken strtof(), so substitute its implementation.
# That's not a perfect fix, since it doesn't avoid double-rounding,
2022-08-07 03:42:11 +03:00
# but we have no better options.
2019-12-19 10:28:37 +03:00
AC_LIBOBJ([strtof])
AC_MSG_NOTICE([On $host_os we will use our strtof wrapper.])
fi
2019-02-16 04:50:16 +03:00
2008-02-24 08:21:54 +03:00
# Similarly, use system's getopt_long() only if system provides struct option.
2009-03-27 22:58:11 +03:00
if test x"$ac_cv_type_struct_option" = xyes ; then
2003-08-08 01:11:58 +04:00
AC_REPLACE_FUNCS([getopt_long])
else
AC_LIBOBJ(getopt_long)
fi
2019-01-18 23:06:26 +03: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-27 22:58:11 +03:00
AC_LIBOBJ(getopt)
fi
2010-12-16 07:50:41 +03: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-15 21:14:24 +03:00
# Win32 (really MinGW) support
2004-09-10 17:53:40 +04:00
if test "$PORTNAME" = "win32"; then
2019-01-22 00:17:10 +03:00
AC_CHECK_FUNCS(_configthreadlocale)
2015-03-14 21:08:45 +03:00
AC_LIBOBJ(dirmod)
2010-12-16 07:50:41 +03: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 17:07:40 +04:00
AC_LIBOBJ(system)
Fix detection of unseekable files for fseek() and ftello() with MSVC
Calling fseek() or ftello() on a handle to a non-seeking device such as
a pipe or a communications device is not supported. Unfortunately,
MSVC's flavor of these routines, _fseeki64() and _ftelli64(), do not
return an error when given a pipe as handle. Some of the logic of
pg_dump and restore relies on these routines to check if a handle is
seekable, causing failures when passing the contents of pg_dump to
pg_restore through a pipe, for example.
This commit introduces wrappers for fseeko() and ftello() on MSVC so as
any callers are able to properly detect the cases of non-seekable
handles. This relies mainly on GetFileType(), sharing a bit of code
with the MSVC port for fstat(). The code in charge of getting a file
type is refactored into a new file called win32common.c, shared by
win32stat.c and the new win32fseek.c. It includes the MSVC ports for
fseeko() and ftello().
Like 765f5df, this is backpatched down to 14, where the fstat()
implementation for MSVC is able to understand about files larger than
4GB in size. Using a TAP test for that is proving to be tricky as
IPC::Run handles the pipes by itself, still I have been able to check
the fix manually.
Reported-by: Daniel Watzinger
Author: Juan José Santamaría Flecha, Michael Paquier
Discussion: https://postgr.es/m/CAC+AXB26a4EmxM2suXxPpJaGrqAdxracd7hskLg-zxtPB50h7A@mail.gmail.com
Backpatch-through: 14
2023-04-12 03:09:38 +03:00
AC_LIBOBJ(win32common)
2022-08-05 00:12:45 +03:00
AC_LIBOBJ(win32dlopen)
2010-12-16 07:50:41 +03:00
AC_LIBOBJ(win32env)
AC_LIBOBJ(win32error)
2022-08-05 07:10:05 +03:00
AC_LIBOBJ(win32fdatasync)
2024-02-12 00:47:57 +03:00
AC_LIBOBJ(win32gai_strerror)
2022-08-13 14:35:24 +03:00
AC_LIBOBJ(win32getrusage)
2022-08-05 00:36:50 +03:00
AC_LIBOBJ(win32link)
2021-12-10 06:13:14 +03:00
AC_LIBOBJ(win32ntdll)
2022-08-05 00:42:31 +03:00
AC_LIBOBJ(win32pread)
AC_LIBOBJ(win32pwrite)
2016-01-08 00:50:28 +03:00
AC_LIBOBJ(win32security)
2011-09-01 15:02:40 +04:00
AC_LIBOBJ(win32setlocale)
2020-10-09 23:20:12 +03:00
AC_LIBOBJ(win32stat)
2004-09-10 17:53:40 +04:00
fi
2015-03-15 21:14:24 +03:00
# Cygwin needs only a bit of that
if test "$PORTNAME" = "cygwin"; then
AC_LIBOBJ(dirmod)
fi
2002-12-15 06:16:58 +03:00
AC_CHECK_FUNC(syslog,
2003-04-07 02:45:23 +04:00
[AC_CHECK_HEADER(syslog.h,
[AC_DEFINE(HAVE_SYSLOG, 1, [Define to 1 if you have the syslog interface.])])])
2000-05-31 04:28:42 +04:00
2009-04-05 01:55:50 +04:00
AC_CACHE_CHECK([for opterr], pgac_cv_var_int_opterr,
2015-07-02 19:21:23 +03:00
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <unistd.h>],
[extern int opterr; opterr = 1;])],
2009-04-05 01:55:50 +04: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 01:18:10 +03:00
AC_CACHE_CHECK([for optreset], pgac_cv_var_int_optreset,
2015-07-02 19:21:23 +03:00
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <unistd.h>],
[extern int optreset; optreset = 1;])],
2000-11-07 01:18:10 +03: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 02:45:23 +04:00
AC_DEFINE(HAVE_INT_OPTRESET, 1, [Define to 1 if you have the global variable 'int optreset'.])
2000-11-07 01:18:10 +03:00
fi
2017-03-23 22:25:34 +03:00
if test "$with_icu" = yes; then
2017-08-05 18:47:28 +03: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-23 22:25:34 +03:00
2017-08-05 18:47:28 +03:00
CPPFLAGS=$ac_save_CPPFLAGS
2017-03-23 22:25:34 +03:00
fi
2018-11-19 20:43:05 +03:00
if test "$with_llvm" = yes; then
PGAC_CHECK_LLVM_FUNCTIONS()
fi
2012-12-19 01:22:13 +04: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-23 19:07:12 +03:00
PGAC_READLINE_VARIABLES
2021-12-02 21:06:27 +03:00
AC_CHECK_FUNCS(m4_normalize([
append_history
history_truncate_file
rl_completion_matches
rl_filename_completion_function
rl_reset_screen_size
rl_variable_bind
]))
2012-12-19 01:22:13 +04:00
fi
2002-08-20 21:54:45 +04:00
2001-03-14 21:00:09 +03: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-02 19:21:23 +03:00
AC_RUN_IFELSE([AC_LANG_SOURCE([int main() { return 0; }])],
2001-03-14 21:00:09 +03:00
[AC_MSG_RESULT(ok)],
[AC_MSG_RESULT(failed)
AC_MSG_ERROR([[
2006-10-16 21:24:54 +04: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-14 21:00:09 +03:00
[AC_MSG_RESULT([cross-compiling])])
2005-12-06 21:35:10 +03:00
# --------------------
# Run tests below here
# --------------------
2001-03-14 21:00:09 +03:00
1999-02-03 03:18:53 +03:00
dnl Check to see if we have a working 64-bit integer type.
2018-05-23 21:19:04 +03: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 03:25:05 +03:00
2000-06-11 15:40:09 +04:00
PGAC_TYPE_64BIT_INT([long int])
1999-02-03 03:18:53 +03:00
2012-10-08 05:52:07 +04:00
if test x"$HAVE_LONG_INT_64" = x"yes" ; then
pg_int64_type="long int"
else
2000-06-11 15:40:09 +04:00
PGAC_TYPE_64BIT_INT([long long int])
2012-10-08 05:52:07 +04:00
if test x"$HAVE_LONG_LONG_INT_64" = x"yes" ; then
pg_int64_type="long long int"
else
2010-01-07 03:25:05 +03:00
AC_MSG_ERROR([Cannot find a working 64-bit integer type.])
fi
1999-03-08 00:32:06 +03:00
fi
2012-10-08 05:52:07 +04:00
AC_DEFINE_UNQUOTED(PG_INT64_TYPE, $pg_int64_type,
[Define to the name of a signed 64-bit integer type.])
2000-06-11 15:40:09 +04:00
2018-05-23 21:19:04 +03: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 04:43:07 +03:00
else
2018-05-23 21:19:04 +03:00
INT64_MODIFIER='"l"'
1999-03-08 00:32:06 +03:00
fi
2014-08-21 10:56:44 +04:00
AC_DEFINE_UNQUOTED(INT64_MODIFIER, $INT64_MODIFIER,
2018-05-23 21:19:04 +03:00
[Define to the appropriate printf length modifier for 64-bit ints.])
2004-02-10 22:55:45 +03:00
2017-10-30 08:13:54 +03:00
# has to be down here, rather than with the other builtins, because
# the test uses PG_INT64_TYPE.
PGAC_C_BUILTIN_OP_OVERFLOW
2009-12-31 22:41:37 +03:00
# Check size of void *, size_t (enables tweaks for > 32bit address space)
2009-01-06 18:38:44 +03:00
AC_CHECK_SIZEOF([void *])
2005-08-21 03:26:37 +04:00
AC_CHECK_SIZEOF([size_t])
2009-12-31 22:41:37 +03:00
AC_CHECK_SIZEOF([long])
2005-08-21 03:26:37 +04:00
2002-03-29 20:32:55 +03:00
# Determine memory alignment requirements for the basic C data types.
1999-03-25 22:05:19 +03:00
2008-02-17 19:36:43 +03:00
AC_CHECK_ALIGNOF(short)
AC_CHECK_ALIGNOF(int)
AC_CHECK_ALIGNOF(long)
2002-03-29 20:32:55 +03:00
if test x"$HAVE_LONG_LONG_INT_64" = x"yes" ; then
2008-02-17 19:36:43 +03:00
AC_CHECK_ALIGNOF(long long int)
1999-03-25 22:05:19 +03:00
fi
2008-02-17 19:36:43 +03:00
AC_CHECK_ALIGNOF(double)
1999-03-25 22:05:19 +03:00
2002-03-29 20:32:55 +03:00
# Compute maximum alignment of any basic type.
Remove AIX support
There isn't a lot of user demand for AIX support, we have a bunch of
hacks to work around AIX-specific compiler bugs and idiosyncrasies,
and no one has stepped up to the plate to properly maintain it.
Remove support for AIX to get rid of that maintenance overhead. It's
still supported for stable versions.
The acute issue that triggered this decision was that after commit
8af2565248, the AIX buildfarm members have been hitting this
assertion:
TRAP: failed Assert("(uintptr_t) buffer == TYPEALIGN(PG_IO_ALIGN_SIZE, buffer)"), File: "md.c", Line: 472, PID: 2949728
Apperently the "pg_attribute_aligned(a)" attribute doesn't work on AIX
for values larger than PG_IO_ALIGN_SIZE, for a static const variable.
That could be worked around, but we decided to just drop the AIX support
instead.
Discussion: https://www.postgresql.org/message-id/20240224172345.32@rfd.leadboat.com
Reviewed-by: Andres Freund, Noah Misch, Thomas Munro
2024-02-28 14:10:51 +03:00
#
# We require 'double' to have the strictest alignment among the basic types,
# because otherwise the C ABI might impose 8-byte alignment on some of the
# other C types that correspond to TYPALIGN_DOUBLE SQL types. That could
# cause a mismatch between the tuple layout and the C struct layout of a
# catalog tuple. We used to carefully order catalog columns such that any
# fixed-width, attalign=4 columns were at offsets divisible by 8 regardless
# of MAXIMUM_ALIGNOF to avoid that, but we no longer support any platforms
# where TYPALIGN_DOUBLE != MAXIMUM_ALIGNOF.
#
# We assume without checking that long's alignment is at least as strong as
# char, short, or int. 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.
MAX_ALIGNOF=$ac_cv_alignof_double
if test $ac_cv_alignof_long -gt $MAX_ALIGNOF ; then
AC_MSG_ERROR([alignment of 'long' is greater than the alignment of 'double'])
fi
if test x"$HAVE_LONG_LONG_INT_64" = xyes && test $ac_cv_alignof_long_long_int -gt $MAX_ALIGNOF ; then
AC_MSG_ERROR([alignment of 'long long int' is greater than the alignment of 'double'])
1999-03-25 22:05:19 +03:00
fi
2003-04-07 02:45:23 +04:00
AC_DEFINE_UNQUOTED(MAXIMUM_ALIGNOF, $MAX_ALIGNOF, [Define as the maximum alignment requirement of any C data type.])
2000-06-11 15:40:09 +04:00
2001-12-02 14:38:40 +03:00
2001-11-15 19:09:34 +03:00
# Some platforms predefine the types int8, int16, etc. Only check
2002-03-29 20:32:55 +03:00
# a (hopefully) representative subset.
AC_CHECK_TYPES([int8, uint8, int64, uint64], [], [],
2012-05-14 05:47:48 +04:00
[#include <stdio.h>])
2001-12-02 14:38:40 +03:00
2017-11-14 23:03:55 +03: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 12:26:17 +03: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 01:49:05 +04: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-15 19:09:34 +03: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 17:05:03 +03:00
# Check for x86 cpuid instruction
AC_CACHE_CHECK([for __get_cpuid], [pgac_cv__get_cpuid],
2015-07-02 19:21:23 +03: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 17:05:03 +03:00
__get_cpuid(1, &exx[0], &exx[1], &exx[2], &exx[3]);
2015-07-02 19:21:23 +03: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 17:05:03 +03: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
Optimize pg_popcount() with AVX-512 instructions.
Presently, pg_popcount() processes data in 32-bit or 64-bit chunks
when possible. Newer hardware that supports AVX-512 instructions
can use 512-bit chunks, which provides a nice speedup, especially
for larger buffers. This commit introduces the infrastructure
required to detect compiler and CPU support for the required
AVX-512 intrinsic functions, and it adds a new pg_popcount()
implementation that uses these functions. If CPU support for this
optimized implementation is detected at runtime, a function pointer
is updated so that it is used by subsequent calls to pg_popcount().
Most of the existing in-tree calls to pg_popcount() should benefit
from these instructions, and calls with smaller buffers should at
least not regress compared to v16. The new infrastructure
introduced by this commit can also be used to optimize
visibilitymap_count(), but that is left for a follow-up commit.
Co-authored-by: Paul Amonson, Ants Aasma
Reviewed-by: Matthias van de Meent, Tom Lane, Noah Misch, Akash Shankaran, Alvaro Herrera, Andres Freund, David Rowley
Discussion: https://postgr.es/m/BL1PR11MB5304097DF7EA81D04C33F3D1DCA6A%40BL1PR11MB5304.namprd11.prod.outlook.com
2024-04-07 05:56:23 +03:00
AC_CACHE_CHECK([for __get_cpuid_count], [pgac_cv__get_cpuid_count],
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <cpuid.h>],
[[unsigned int exx[4] = {0, 0, 0, 0};
__get_cpuid_count(7, 0, &exx[0], &exx[1], &exx[2], &exx[3]);
]])],
[pgac_cv__get_cpuid_count="yes"],
[pgac_cv__get_cpuid_count="no"])])
if test x"$pgac_cv__get_cpuid_count" = x"yes"; then
AC_DEFINE(HAVE__GET_CPUID_COUNT, 1, [Define to 1 if you have __get_cpuid_count.])
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 17:05:03 +03:00
AC_CACHE_CHECK([for __cpuid], [pgac_cv__cpuid],
2015-07-02 19:21:23 +03: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 17:05:03 +03:00
__get_cpuid(exx[0], 1);
2015-07-02 19:21:23 +03: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 17:05:03 +03: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
Optimize pg_popcount() with AVX-512 instructions.
Presently, pg_popcount() processes data in 32-bit or 64-bit chunks
when possible. Newer hardware that supports AVX-512 instructions
can use 512-bit chunks, which provides a nice speedup, especially
for larger buffers. This commit introduces the infrastructure
required to detect compiler and CPU support for the required
AVX-512 intrinsic functions, and it adds a new pg_popcount()
implementation that uses these functions. If CPU support for this
optimized implementation is detected at runtime, a function pointer
is updated so that it is used by subsequent calls to pg_popcount().
Most of the existing in-tree calls to pg_popcount() should benefit
from these instructions, and calls with smaller buffers should at
least not regress compared to v16. The new infrastructure
introduced by this commit can also be used to optimize
visibilitymap_count(), but that is left for a follow-up commit.
Co-authored-by: Paul Amonson, Ants Aasma
Reviewed-by: Matthias van de Meent, Tom Lane, Noah Misch, Akash Shankaran, Alvaro Herrera, Andres Freund, David Rowley
Discussion: https://postgr.es/m/BL1PR11MB5304097DF7EA81D04C33F3D1DCA6A%40BL1PR11MB5304.namprd11.prod.outlook.com
2024-04-07 05:56:23 +03:00
AC_CACHE_CHECK([for __cpuidex], [pgac_cv__cpuidex],
[AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <intrin.h>],
[[unsigned int exx[4] = {0, 0, 0, 0};
__get_cpuidex(exx[0], 7, 0);
]])],
[pgac_cv__cpuidex="yes"],
[pgac_cv__cpuidex="no"])])
if test x"$pgac_cv__cpuidex" = x"yes"; then
AC_DEFINE(HAVE__CPUIDEX, 1, [Define to 1 if you have __cpuidex.])
fi
# Check for XSAVE intrinsics
#
CFLAGS_XSAVE=""
PGAC_XSAVE_INTRINSICS([])
if test x"$pgac_xsave_intrinsics" != x"yes"; then
PGAC_XSAVE_INTRINSICS([-mxsave])
fi
if test x"$pgac_xsave_intrinsics" = x"yes"; then
AC_DEFINE(HAVE_XSAVE_INTRINSICS, 1, [Define to 1 if you have XSAVE intrinsics.])
fi
AC_SUBST(CFLAGS_XSAVE)
# Check for AVX-512 popcount intrinsics
#
CFLAGS_POPCNT=""
PG_POPCNT_OBJS=""
if test x"$host_cpu" = x"x86_64"; then
PGAC_AVX512_POPCNT_INTRINSICS([])
if test x"$pgac_avx512_popcnt_intrinsics" != x"yes"; then
PGAC_AVX512_POPCNT_INTRINSICS([-mavx512vpopcntdq -mavx512bw])
fi
if test x"$pgac_avx512_popcnt_intrinsics" = x"yes"; then
PG_POPCNT_OBJS="pg_popcount_avx512.o pg_popcount_avx512_choose.o"
AC_DEFINE(USE_AVX512_POPCNT_WITH_RUNTIME_CHECK, 1, [Define to 1 to use AVX-512 popcount instructions with a runtime check.])
fi
fi
AC_SUBST(CFLAGS_POPCNT)
AC_SUBST(PG_POPCNT_OBJS)
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 17:05:03 +03:00
# Check for Intel SSE 4.2 intrinsics to do CRC calculations.
#
2015-04-14 19:56:03 +03: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 17:05:03 +03:00
# with the default compiler flags. If not, check if adding the -msse4.2
2022-12-02 05:46:55 +03:00
# flag helps. CFLAGS_CRC is set to -msse4.2 if that's required.
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 17:05:03 +03:00
PGAC_SSE42_CRC32_INTRINSICS([])
if test x"$pgac_sse42_crc32_intrinsics" != x"yes"; then
PGAC_SSE42_CRC32_INTRINSICS([-msse4.2])
fi
2015-04-14 19:56:03 +03:00
# Are we targeting a processor that supports SSE 4.2? gcc, clang and icc all
# define __SSE4_2__ in that case.
2015-07-02 19:21:23 +03:00
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [
2015-04-14 19:56:03 +03:00
#ifndef __SSE4_2__
#error __SSE4_2__ not defined
#endif
2015-07-02 19:21:23 +03:00
])], [SSE4_2_TARGETED=1])
2015-04-14 19:56:03 +03: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 12:22:45 +03: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.
2022-12-02 05:46:55 +03:00
# CFLAGS_CRC is set if the extra flag is required.
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 12:22:45 +03:00
PGAC_ARMV8_CRC32C_INTRINSICS([])
if test x"$pgac_armv8_crc32c_intrinsics" != x"yes"; then
PGAC_ARMV8_CRC32C_INTRINSICS([-march=armv8-a+crc])
fi
2022-12-02 05:46:55 +03:00
2023-08-10 07:36:15 +03:00
# Check for LoongArch CRC intrinsics to do CRC calculations.
#
# Check if __builtin_loongarch_crcc_* intrinsics can be used
# with the default compiler flags.
PGAC_LOONGARCH_CRC32C_INTRINSICS()
2022-12-02 05:46:55 +03:00
AC_SUBST(CFLAGS_CRC)
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 12:22:45 +03: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 17:05:03 +03: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 12:22:45 +03: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 17:05:03 +03:00
#
2023-08-10 07:36:15 +03:00
# You can skip the runtime check by setting the appropriate USE_*_CRC32 flag to 1
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 17:05:03 +03:00
# in the template or configure command line.
2023-08-10 07:36:15 +03:00
#
# If we are targeting a LoongArch processor, CRC instructions are
# always available (at least on 64 bit), so no runtime check is needed.
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"" && test x"$USE_LOONGARCH_CRC32C" = x""; 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 12:22:45 +03:00
# Use Intel SSE 4.2 if available.
2015-04-14 19:56:03 +03: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 17:05:03 +03: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 12:22:45 +03: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 17:05:03 +03: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 12:22:45 +03:00
# Use ARM CRC Extension if available.
2022-12-02 05:46:55 +03:00
if test x"$pgac_armv8_crc32c_intrinsics" = x"yes" && test x"$CFLAGS_CRC" = x""; 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 12:22:45 +03:00
USE_ARMV8_CRC32C=1
else
2018-05-03 01:06:43 +03: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 12:22:45 +03:00
USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK=1
else
2023-08-10 07:36:15 +03:00
# LoongArch CRCC instructions.
if test x"$pgac_loongarch_crc32c_intrinsics" = x"yes"; then
USE_LOONGARCH_CRC32C=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 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 12:22:45 +03:00
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 17:05:03 +03: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 11:20:53 +03: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 12:22:45 +03: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 17:05:03 +03: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 12:22:45 +03: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
2023-08-10 07:36:15 +03:00
if test x"$USE_LOONGARCH_CRC32C" = x"1"; then
AC_DEFINE(USE_LOONGARCH_CRC32C, 1, [Define to 1 to use LoongArch CRCC instructions.])
PG_CRC32C_OBJS="pg_crc32c_loongarch.o"
AC_MSG_RESULT(LoongArch CRCC instructions)
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
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 12:22:45 +03:00
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 17:05:03 +03:00
fi
fi
AC_SUBST(PG_CRC32C_OBJS)
2002-05-05 04:03:29 +04:00
# Select semaphore implementation type.
2006-04-29 20:34:41 +04: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 01:03:45 +03: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-29 20:34:41 +04: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 04:03:29 +04: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 01:03:45 +03:00
sematype="named POSIX"
2002-05-05 04:03:29 +04:00
else
2006-04-29 20:34:41 +04: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 01:03:45 +03:00
sematype="unnamed POSIX"
2006-04-29 20:34:41 +04: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 01:03:45 +03:00
sematype="System V"
2006-04-29 20:34:41 +04:00
fi
2002-05-05 04:03:29 +04:00
fi
2016-12-07 03:34:29 +03:00
AC_MSG_RESULT([$sematype])
2006-04-29 20:34:41 +04: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 04:03:29 +04:00
fi
# Select shared-memory implementation type.
2007-03-21 17:39:23 +03: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 04:03:29 +04:00
2020-11-20 14:26:57 +03:00
# Select random number source. If a TLS library is used then it will be the
# first choice, else the native platform sources (Windows API or /dev/urandom)
# will be used.
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 14:42:59 +03:00
AC_MSG_CHECKING([which random number source to use])
2021-02-01 13:19:44 +03:00
if test x"$with_ssl" = x"openssl" ; then
2019-01-01 14:05:51 +03:00
AC_MSG_RESULT([OpenSSL])
2020-11-20 14:26:57 +03:00
elif test x"$PORTNAME" = x"win32" ; then
2019-01-01 14:05:51 +03:00
AC_MSG_RESULT([Windows native])
2021-12-01 01:18:04 +03:00
elif test x"$cross_compiling" = x"yes"; then
AC_MSG_RESULT([assuming /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 14:42:59 +03:00
else
2020-11-20 14:26:57 +03:00
AC_MSG_RESULT([/dev/urandom])
AC_CHECK_FILE([/dev/urandom], [], [])
if test x"$ac_cv_file__dev_urandom" = x"no" ; then
AC_MSG_ERROR([
2019-01-01 14:05:51 +03:00
no source of strong random numbers was found
2020-11-20 14:26:57 +03:00
PostgreSQL can use OpenSSL, native Windows API or /dev/urandom as a source of random numbers.])
fi
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 14:42:59 +03:00
fi
2006-02-03 16:53:15 +03: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 03:20:15 +03:00
if test "$enable_nls" = yes ; then
PGAC_CHECK_GETTEXT
fi
2000-09-26 02:23:01 +04:00
# Check for Tcl configuration script tclConfig.sh
if test "$with_tcl" = yes; then
PGAC_PATH_TCLCONFIGSH([$with_tclconfig])
2002-05-24 22:10:17 +04: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 04:38:21 +03:00
[TCL_INCLUDE_SPEC,TCL_LIBS,TCL_LIB_SPEC,TCL_SHARED_BUILD])
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-16 23:41:01 +03: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 19:58:16 +04:00
fi
2013-01-10 04:41:37 +04: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-18 21:55:23 +03:00
CPPFLAGS="$CPPFLAGS $perl_includespec"
2013-01-10 04:41:37 +04: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-21 20:52:25 +03: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 04:41:37 +04:00
pgac_save_LIBS=$LIBS
2013-01-10 08:46:44 +04:00
LIBS="$perl_embed_ldflags"
2013-01-10 04:41:37 +04:00
AC_MSG_CHECKING([for libperl])
2015-07-02 19:21:23 +03:00
AC_LINK_IFELSE([AC_LANG_PROGRAM([
2013-01-10 04:41:37 +04:00
#include <EXTERN.h>
#include <perl.h>
2015-07-02 19:21:23 +03:00
], [perl_alloc();])],
2013-01-10 04:41:37 +04:00
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
AC_MSG_ERROR([libperl library is required for Perl])])
LIBS=$pgac_save_LIBS
2019-10-21 20:52:25 +03:00
CFLAGS=$ac_save_CFLAGS
2013-01-10 04:41:37 +04:00
CPPFLAGS=$ac_save_CPPFLAGS
fi
2011-02-26 22:17:57 +03: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 00:04:07 +03:00
#
Remove configure-time probe for DocBook DTD.
Checking for DocBook being installed was valuable when we were on the
OpenSP docs toolchain, because that was rather hard to get installed
fully. Nowadays, as long as you have xmllint and xsltproc installed,
you're good, because those programs will fetch the DocBook files off
the net at need. Moreover, testing this at configure time means that
a network access may well occur whether or not you have any interest
in building the docs later. That can be slow (typically 2 or 3
seconds, though much higher delays have been reported), and it seems
not very nice to be doing an off-machine access without warning, too.
Hence, drop the PGAC_CHECK_DOCBOOK probe, and adjust related
documentation. Without that macro, there's not much left of
config/docbook.m4 at all, so I just removed it.
Back-patch to v11, where we started to use xmllint in the
PGAC_CHECK_DOCBOOK probe.
Discussion: https://postgr.es/m/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se
Discussion: https://postgr.es/m/A55A7FC9-FA60-47FE-98B5-139CDC57CE6E@gmail.com
2020-11-30 23:24:13 +03:00
# Check for documentation-building tools
2000-11-06 00:04:07 +03:00
#
Remove configure-time probe for DocBook DTD.
Checking for DocBook being installed was valuable when we were on the
OpenSP docs toolchain, because that was rather hard to get installed
fully. Nowadays, as long as you have xmllint and xsltproc installed,
you're good, because those programs will fetch the DocBook files off
the net at need. Moreover, testing this at configure time means that
a network access may well occur whether or not you have any interest
in building the docs later. That can be slow (typically 2 or 3
seconds, though much higher delays have been reported), and it seems
not very nice to be doing an off-machine access without warning, too.
Hence, drop the PGAC_CHECK_DOCBOOK probe, and adjust related
documentation. Without that macro, there's not much left of
config/docbook.m4 at all, so I just removed it.
Back-patch to v11, where we started to use xmllint in the
PGAC_CHECK_DOCBOOK probe.
Discussion: https://postgr.es/m/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se
Discussion: https://postgr.es/m/A55A7FC9-FA60-47FE-98B5-139CDC57CE6E@gmail.com
2020-11-30 23:24:13 +03:00
PGAC_PATH_PROGS(XMLLINT, xmllint)
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 18:40:00 +03:00
PGAC_PATH_PROGS(XSLTPROC, xsltproc)
PGAC_PATH_PROGS(FOP, fop)
Remove configure-time probe for DocBook DTD.
Checking for DocBook being installed was valuable when we were on the
OpenSP docs toolchain, because that was rather hard to get installed
fully. Nowadays, as long as you have xmllint and xsltproc installed,
you're good, because those programs will fetch the DocBook files off
the net at need. Moreover, testing this at configure time means that
a network access may well occur whether or not you have any interest
in building the docs later. That can be slow (typically 2 or 3
seconds, though much higher delays have been reported), and it seems
not very nice to be doing an off-machine access without warning, too.
Hence, drop the PGAC_CHECK_DOCBOOK probe, and adjust related
documentation. Without that macro, there's not much left of
config/docbook.m4 at all, so I just removed it.
Back-patch to v11, where we started to use xmllint in the
PGAC_CHECK_DOCBOOK probe.
Discussion: https://postgr.es/m/E2EE6B76-2D96-408A-B961-CAE47D1A86F0@yesql.se
Discussion: https://postgr.es/m/A55A7FC9-FA60-47FE-98B5-139CDC57CE6E@gmail.com
2020-11-30 23:24:13 +03:00
PGAC_PATH_PROGS(DBTOEPUB, dbtoepub)
2000-11-06 00:04:07 +03:00
2014-04-15 05:33:46 +04:00
#
# Check for test tools
#
2014-11-02 17:14:36 +03:00
if test "$enable_tap_tests" = yes; then
2021-11-22 20:54:52 +03:00
# 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 18:40:00 +03:00
PGAC_PATH_PROGS(PROVE, prove)
2014-11-02 17:14:36 +03:00
if test -z "$PROVE"; then
AC_MSG_ERROR([prove not found])
fi
2021-11-22 20:54:52 +03:00
# Check for necessary Perl modules. You might think we should use
# AX_PROG_PERL_MODULES here, but prove might be part of a different Perl
# installation than perl, eg on MSys, so we have to check using prove.
AC_MSG_CHECKING(for Perl modules required for TAP tests)
2022-02-19 00:59:30 +03:00
__CONFIG_HOST_OS__=$host_os; export __CONFIG_HOST_OS__
2021-11-22 20:54:52 +03:00
[modulestderr=`"$PROVE" "$srcdir/config/check_modules.pl" 2>&1 >/dev/null`]
if test $? -eq 0; then
# log the module version details, but don't show them interactively
echo "$modulestderr" >&AS_MESSAGE_LOG_FD
AC_MSG_RESULT(yes)
else
# on failure, though, show the results to the user
AC_MSG_RESULT([$modulestderr])
AC_MSG_ERROR([Additional Perl modules are required to run TAP tests])
fi
2014-11-02 17:14:36 +03:00
fi
2014-04-15 05:33:46 +04:00
2009-06-11 01:24:11 +04: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 07:30:22 +04: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 01:24:11 +04:00
if test "$PORTNAME" = "darwin"; then
2008-05-20 07:30:22 +04:00
PGAC_PROG_CC_LDFLAGS_OPT([-Wl,-dead_strip_dylibs], $link_test_func)
2009-06-11 01:24:11 +04: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 07:30:22 +04:00
fi
2022-12-07 05:55:28 +03:00
# For linkers that understand --export-dynamic, add that to the LDFLAGS_EX_BE
# (backend specific ldflags). One some platforms this will always fail (e.g.,
# windows), but on others it depends on the choice of linker (e.g., solaris).
PGAC_PROG_CC_LD_VARFLAGS_OPT(LDFLAGS_EX_BE, [-Wl,--export-dynamic], $link_test_func)
AC_SUBST(LDFLAGS_EX_BE)
2009-01-06 18:38:44 +03:00
# Create compiler version string
if test x"$GCC" = x"yes" ; then
2011-05-06 23:14:53 +04:00
cc_string=`${CC} --version | sed q`
case $cc_string in [[A-Za-z]]*) ;; *) cc_string="GCC $cc_string";; esac
2009-01-07 13:38:44 +03:00
elif test x"$SUN_STUDIO_CC" = x"yes" ; then
cc_string=`${CC} -V 2>&1 | sed q`
2009-01-06 18:38:44 +03:00
else
cc_string=$CC
fi
AC_DEFINE_UNQUOTED(PG_VERSION_STR,
2013-12-13 06:53:21 +04:00
["PostgreSQL $PG_VERSION on $host, compiled by $cc_string, `expr $ac_cv_sizeof_void_p \* 8`-bit"],
2009-01-06 18:38:44 +03: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
2020-03-10 19:46:07 +03:00
[PG_VERSION_NUM="`echo $PG_MAJORVERSION $PG_MINORVERSION |
2017-11-07 03:46:52 +03:00
$AWK '{printf "%d%04d", $1, $2}'`"]
2009-01-06 18:38:44 +03:00
AC_DEFINE_UNQUOTED(PG_VERSION_NUM, $PG_VERSION_NUM, [PostgreSQL version as a number])
2015-07-03 00:24:36 +03:00
AC_SUBST(PG_VERSION_NUM)
2009-01-06 18:38:44 +03:00
2018-11-03 01:54:00 +03: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.
On macOS, use -isysroot in link steps as well as compile steps.
We previously put the -isysroot switch only into CPPFLAGS, theorizing
that it was only needed to find the right copies of include files.
However, it seems that we also need to use it while linking programs,
to find the right stub ".tbd" files for libraries. We got away
without that up to now, but apparently that was mostly luck. It may
also be that failures are only observed when the Xcode version is
noticeably out of sync with the host macOS version; the case that's
prompting action right now is that builds fail when using latest Xcode
(12.2) on macOS Catalina, even though it's fine on Big Sur.
Hence, add -isysroot to LDFLAGS as well. (It seems that the more
common practice is to put it in CFLAGS, whence it'd be included at
both compile and link steps. However, we can't mess with CFLAGS in
the platform template file without confusing configure's logic for
choosing default CFLAGS.)
This should be back-patched, but first let's see if the buildfarm
likes it on HEAD.
Report and patch by James Hilliard (some cosmetic mods by me)
Discussion: https://postgr.es/m/20201120003314.20560-1-james.hilliard1@gmail.com
2020-11-20 08:07:09 +03:00
# The same for LDFLAGS, too.
2018-11-03 01:54:00 +03:00
if test x"$PG_SYSROOT" != x; then
CPPFLAGS=`echo "$CPPFLAGS" | sed -e "s| $PG_SYSROOT | \\\$(PG_SYSROOT) |"`
On macOS, use -isysroot in link steps as well as compile steps.
We previously put the -isysroot switch only into CPPFLAGS, theorizing
that it was only needed to find the right copies of include files.
However, it seems that we also need to use it while linking programs,
to find the right stub ".tbd" files for libraries. We got away
without that up to now, but apparently that was mostly luck. It may
also be that failures are only observed when the Xcode version is
noticeably out of sync with the host macOS version; the case that's
prompting action right now is that builds fail when using latest Xcode
(12.2) on macOS Catalina, even though it's fine on Big Sur.
Hence, add -isysroot to LDFLAGS as well. (It seems that the more
common practice is to put it in CFLAGS, whence it'd be included at
both compile and link steps. However, we can't mess with CFLAGS in
the platform template file without confusing configure's logic for
choosing default CFLAGS.)
This should be back-patched, but first let's see if the buildfarm
likes it on HEAD.
Report and patch by James Hilliard (some cosmetic mods by me)
Discussion: https://postgr.es/m/20201120003314.20560-1-james.hilliard1@gmail.com
2020-11-20 08:07:09 +03:00
LDFLAGS=`echo "$LDFLAGS" | sed -e "s| $PG_SYSROOT | \\\$(PG_SYSROOT) |"`
2018-11-03 01:54:00 +03:00
fi
AC_SUBST(PG_SYSROOT)
2009-01-06 18:38:44 +03:00
2011-08-29 01:14:52 +04: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 03:26:25 +03: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 01:14:52 +04:00
2001-03-03 18:53:41 +03:00
# prepare build tree if outside source tree
2001-09-11 03:52:04 +04: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-27 21:14:02 +03: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-29 20:32:55 +03: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 18:53:41 +03:00
|| AC_MSG_ERROR(failed)
AC_MSG_RESULT(done)
2002-03-29 20:32:55 +03:00
fi
2000-10-21 01:04:27 +04:00
fi
2003-11-27 21:14:02 +03:00
AC_SUBST(vpath_build)
2000-10-21 01:04:27 +04:00
2002-03-29 20:32:55 +03:00
AC_CONFIG_FILES([GNUmakefile src/Makefile.global])
AC_CONFIG_LINKS([
2002-05-05 04:03:29 +04:00
src/backend/port/pg_sema.c:${SEMA_IMPLEMENTATION}
src/backend/port/pg_shmem.c:${SHMEM_IMPLEMENTATION}
2002-03-29 20:32:55 +03:00
src/include/pg_config_os.h:src/include/port/${template}.h
src/Makefile.port:src/makefiles/Makefile.${template}
])
2004-09-10 17:53:40 +04:00
if test "$PORTNAME" = "win32"; then
2004-05-18 08:10:33 +04:00
AC_CONFIG_COMMANDS([check_win32_symlinks],[
2010-11-23 23:27:50 +03:00
# Links sometimes fail undetected on Mingw -
2004-05-13 05:45:02 +04:00
# so here we detect it and warn the user
2004-05-29 00:52:42 +04:00
for FILE in $CONFIG_LINKS
2004-05-13 05:45:02 +04:00
do
# test -e works for symlinks in the MinGW console
2006-10-16 21:24:54 +04:00
test -e `expr "$FILE" : '\([[^:]]*\)'` || AC_MSG_WARN([*** link for $FILE -- please fix by hand])
2004-05-13 05:45:02 +04:00
done
2004-05-17 23:14:47 +04:00
])
2004-09-10 17:53:40 +04:00
fi
2004-05-13 05:45:02 +04:00
2004-05-17 23:14:47 +04: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 05:52:07 +04: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 01:27:13 +03:00
AC_CONFIG_HEADERS([src/interfaces/ecpg/include/ecpg_config.h],
[echo >src/interfaces/ecpg/include/stamp-h])
2006-08-23 16:01:53 +04:00
2004-05-17 23:14:47 +04:00
AC_OUTPUT
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 07:53:12 +03:00
# Ensure that any meson build directories would reconfigure and see that
# there's a conflicting in-tree build and can error out.
2024-04-25 17:51:33 +03:00
if test "$vpath_build" = "no"; then
meson: Add initial version of meson based build system
Autoconf is showing its age, fewer and fewer contributors know how to wrangle
it. Recursive make has a lot of hard to resolve dependency issues and slow
incremental rebuilds. Our home-grown MSVC build system is hard to maintain for
developers not using Windows and runs tests serially. While these and other
issues could individually be addressed with incremental improvements, together
they seem best addressed by moving to a more modern build system.
After evaluating different build system choices, we chose to use meson, to a
good degree based on the adoption by other open source projects.
We decided that it's more realistic to commit a relatively early version of
the new build system and mature it in tree.
This commit adds an initial version of a meson based build system. It supports
building postgres on at least AIX, FreeBSD, Linux, macOS, NetBSD, OpenBSD,
Solaris and Windows (however only gcc is supported on aix, solaris). For
Windows/MSVC postgres can now be built with ninja (faster, particularly for
incremental builds) and msbuild (supporting the visual studio GUI, but
building slower).
Several aspects (e.g. Windows rc file generation, PGXS compatibility, LLVM
bitcode generation, documentation adjustments) are done in subsequent commits
requiring further review. Other aspects (e.g. not installing test-only
extensions) are not yet addressed.
When building on Windows with msbuild, builds are slower when using a visual
studio version older than 2019, because those versions do not support
MultiToolTask, required by meson for intra-target parallelism.
The plan is to remove the MSVC specific build system in src/tools/msvc soon
after reaching feature parity. However, we're not planning to remove the
autoconf/make build system in the near future. Likely we're going to keep at
least the parts required for PGXS to keep working around until all supported
versions build with meson.
Some initial help for postgres developers is at
https://wiki.postgresql.org/wiki/Meson
With contributions from Thomas Munro, John Naylor, Stone Tickle and others.
Author: Andres Freund <andres@anarazel.de>
Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Author: Peter Eisentraut <peter@eisentraut.org>
Reviewed-By: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211012083721.hvixq4pnh2pixr3j@alap3.anarazel.de
2022-09-22 07:53:12 +03:00
touch meson.build
fi