summaryrefslogtreecommitdiff
path: root/config
Commit message (Collapse)AuthorAgeFilesLines
* Fix typos in commentsMichael Paquier2023-05-021-1/+1
| | | | | | | | | The changes done in this commit impact comments with no direct user-visible changes, with fixes for incorrect function, variable or structure names. Author: Alexander Lakhin Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com
* Use --strip-unneeded when stripping static libraries with GNU strip.Tom Lane2023-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | We've long used "--strip-unneeded" for shared libraries but plain "-x" for static libraries when stripping symbols with GNU strip. There doesn't seem to be any really good reason for that though, since --strip-unneeded produces smaller output (as "-x" alone does not remove debug symbols). Moreover it seems that llvm-strip, although it identifies as GNU strip, misbehaves when given "-x" for this purpose. It's unclear whether that's intentional or a bug in llvm-strip, but in any case it seems like changing to use --strip-unneeded in all cases should be a win. Note that this doesn't change our behavior when dealing with non-GNU strip. Per gripes from Ed Maste and Palle Girgensohn. Back-patch, in case anyone wants to use llvm-strip with stable branches. Discussion: https://postgr.es/m/17898-5308d09543463266@postgresql.org Discussion: https://postgr.es/m/20230420153338.bbj2g5jiyy3afhjz@awork3.anarazel.de
* Update config.guess and config.subPeter Eisentraut2023-04-122-22/+59
|
* autoconf: Move export_dynamic determination to configureAndres Freund2022-12-062-127/+17
| | | | | | | | | | | | | Previously export_dynamic was set in src/makefiles/Makefile.$port. For solaris this required exporting with_gnu_ld. The determination of with_gnu_ld would be nontrivial to copy for meson PGXS compatibility. It's also nice to delete libtool.m4. This uses -Wl,--export-dynamic on all platforms, previously all platforms but FreeBSD used -Wl,-E. The likelihood of a name conflict seems lower with the longer spelling. Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
* autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32CAndres Freund2022-12-011-4/+4
| | | | | | | | | | | | | | | | | | Until now we emitted the cflags to build the CRC objects into architecture specific variables. That doesn't make a whole lot of sense to me - we're never going to target x86 and arm at the same time, so they don't need to be separate variables. It might be better to instead continue to have CFLAGS_SSE42 / CFLAGS_ARMV8_CRC32C be computed by PGAC_ARMV8_CRC32C_INTRINSICS / PGAC_SSE42_CRC32_INTRINSICS and then set CFLAGS_CRC based on those. But it seems unlikely that we'd need other sets of CRC specific flags for those two architectures at the same time. This simplifies the upcoming meson PGXS compatibility. Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
* meson: Add initial version of meson based build systemAndres Freund2022-09-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add definition pg_attribute_aligned() for MSVCMichael Paquier2022-09-211-0/+2
| | | | | | | | | | | | Visual Studio 2015+ has support for a macro to control the alignement of structures as of __declspec(align(#)), and this commit adds a definition of pg_attribute_aligned() based on that. It happens that this was already used in the implementation of atomics for MSVC. Note that there is still no definition fo pg_attribute_packed(), so this does not impact itemptr.h. Author: James Coleman Discussion: https://postgr.es/m/CAAaqYe-HbtZvR3msoMtk+hYW2S0e0OapzMW8icSMYTMA+mN8Aw@mail.gmail.com
* Bump minimum Perl version to 5.14John Naylor2022-09-141-2/+2
| | | | | | | | | | | | | | | | | | | | The oldest vendor-shipped Perl in the buildfarm is 5.14.2, which is the last version that Debian Wheezy shipped. That OS is EOL, but we keep it running because there is no other convenient way to test certain non-mainstream 32-bit platforms. There is no bugfix in the 5.14.2 release that is required, and yet it's also not the latest minor release -- that would be 5.14.4. To clarify the situation, we have thus arranged the buildfarm to test 5.14.0. That allows configure scripts and documentation to state 5.14 without fine print. The MSVC build didn't check the version, since our previous minimum 5.8.3 was considered too old to check for on Windows. We will need a check for Windows sometime during the v16 cycle, but that could be rendered moot by the impending Meson conversion, so it seems safe to just document the requirement for now. Reviewed by Tom Lane Discussion: https://www.postgresql.org/message-id/20220902181553.ev4pgzhubhdkguuv@awork3.anarazel.de
* Bump minimum version of Flex to 2.5.35John Naylor2022-09-091-6/+4
| | | | | | | | Since the retirement of some older buildfarm members, the oldest Flex that gets regular testing is 2.5.35. Reviewed by Andres Freund Discussion: https://www.postgresql.org/message-id/1097762.1662145681@sss.pgh.pa.us
* Bump minimum version of Bison to 2.3John Naylor2022-09-091-4/+4
| | | | | | | | | | | | Since the retirement of some older buildfarm members, the oldest Bison that gets regular testing is 2.3. MacOS ships that version, and will continue doing so for the forseeable future because of Apple's policy regarding GPLv3. While Mac users could use a package manager to install a newer version, there is no compelling reason to force them do so at this time. Reviewed by Andres Freund Discussion: https://www.postgresql.org/message-id/1097762.1662145681@sss.pgh.pa.us
* Remove further unwanted linker flags from perl_embed_ldflagsPeter Eisentraut2022-08-231-5/+5
| | | | | | | | | | | | | | | | | | Remove the contents of $Config{ldflags} from ExtUtils::Embed's ldopts, like we already do with $Config{ccdlflags}. Those flags are the choices of those who built the Perl installation, which are not necessarily appropriate for building PostgreSQL. What we really want from ldopts are the options identifying the location and name of the libperl library, but unfortunately it doesn't appear possible to get that separately from the other stuff. The motivation for this was to strip -mmacosx-version-min options. We already did something similar for the -arch option. Both of those are now covered by this more general approach. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/8c4fcb72-2574-ff7c-4c25-1f032d4a2a57%40enterprisedb.com
* Remove configure probes for sockaddr_storage members.Thomas Munro2022-08-221-12/+6
| | | | | | | | | | | | | | | | | | | | | Remove four probes for members of sockaddr_storage. Keep only the probe for sockaddr's sa_len, which is enough for our two remaining places that know about _len fields: 1. ifaddr.c needs to know if sockaddr has sa_len to understand the result of ioctl(SIOCGIFCONF). Only AIX is still using the relevant code today, but it seems like a good idea to keep it compilable on Linux. 2. ip.c was testing for presence of ss_len to decide whether to fill in sun_len in our getaddrinfo_unix() function. It's just as good to test for sa_len. If you have one, you have them all. (The code in #2 isn't actually needed at all on several OSes I checked since modern versions ignore sa_len on input to system calls. Proving that's the case for all relevant OSes is left for another day, but wouldn't get rid of that last probe anyway if we still want it for #1.) Discussion: https://postgr.es/m/CA%2BhUKGJJjF2AqdU_Aug5n2MAc1gr%3DGykNjVBZq%2Bd6Jrcp3Dyvg%40mail.gmail.com
* Remove replacement code for getaddrinfo.Thomas Munro2022-08-141-11/+0
| | | | | | | | | | SUSv3, all targeted Unixes and modern Windows have getaddrinfo() and related interfaces. Drop the replacement implementation, and adjust some headers slightly to make sure that the APIs are visible everywhere using standard POSIX headers and names. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Remove configure probe for struct sockaddr_storage.Thomas Munro2022-08-141-13/+1
| | | | | | | | <sys/socket.h> provides sockaddr_storage in SUSv3 and all targeted Unix systems have it. Windows has it too. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Remove configure probes for sys/ipc.h, sys/sem.h, sys/shm.h.Thomas Munro2022-08-141-4/+1
| | | | | | | | | These are in SUSv2 and every targeted Unix system has them. It's not hard to avoid including them on Windows system because they're mostly used in platform-specific translation units. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Remove configure probes for sys/un.h and struct sockaddr_un.Thomas Munro2022-08-141-14/+0
| | | | | | | | | | | | | | | | <sys/un.h> is in SUSv3 and every targeted Unix has it. Some Windows tool chains may still lack the approximately equivalent header <afunix.h>, so we already defined struct sockaddr_un ourselves on that OS for now. To harmonize things a bit, move our definition into a new header src/include/port/win32/sys/un.h. HAVE_UNIX_SOCKETS is now defined unconditionally. We migh remove that in a separate commit, pending discussion. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA%2BhUKG%2BL_3brvh%3D8e0BW_VfX9h7MtwgN%3DnFHP5o7X2oZucY9dg%40mail.gmail.com
* Rely on __func__ being supportedAndres Freund2022-08-071-26/+0
| | | | | | | | | | | | Previously we fell back to __FUNCTION__ and then NULL. As __func__ is in C99 that shouldn't be necessary anymore. Solution.pm defined HAVE_FUNCNAME__FUNCTION instead of HAVE_FUNCNAME__FUNC (originating in 4164e6636e2), as at some point in the past MSVC only supported __FUNCTION__. Our minimum version supports __func__. Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20220807012914.ydz73yte6j3coulo@awork3.anarazel.de
* Simplify gettimeofday() fallback logic.Andres Freund2022-08-061-24/+0
| | | | | | | | | | | | | | | | | | There's no known supported system needing 1 argument gettimeofday() support. The test for it was added a long time ago (92c6bf9775b). Remove. Until now we tested whether a gettimeofday() fallback is needed when targetting windows. Which lead to the odd result that HAVE_GETTIMEOFDAY only being defined when targetting MinGW (which has gettimeofday() since at least 2007). As the fallback is specific to msvc, remove the configure code and rename src/port/gettimeofday.c to src/port/win32gettimeofday.c. While at it, also remove the definition of struct timezone, a forward declaration of the struct is sufficient. Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20220806000311.ywx65iuchvj4qn2k@awork3.anarazel.de
* Unify DLSUFFIX on DarwinPeter Eisentraut2022-07-061-10/+5
| | | | | | | | | | | | | | | | | macOS has traditionally used extension .dylib for shared libraries (used at build time) and .so for dynamically loaded modules (used by dlopen()). This complicates the build system a bit. Also, Meson uses .dylib for both, so it would be worth unifying this in order to be able to get equal build output. There doesn't appear to be any reason to use any particular extension for dlopened modules, since dlopen() will accept anything and PostgreSQL is well-factored to be able to deal with any extension. Other software packages that I have handy appear to be about 50/50 split on which extension they use for their plugins. So it seems possible to change this safely. Discussion: https://www.postgresql.org/message-id/flat/bcc45f78-e3c3-8fb3-7c42-5371b48b5266%40enterprisedb.com
* Pre-beta mechanical code beautification.Tom Lane2022-05-121-3/+2
| | | | | Run pgindent, pgperltidy, and reformat-dat-files. I manually fixed a couple of comments that pgindent uglified.
* Update config.guess and config.subPeter Eisentraut2022-04-072-622/+706
|
* Refactor DLSUFFIX handlingPeter Eisentraut2022-03-251-1/+3
| | | | | | | | | | | | Move DLSUFFIX from makefiles into header files for all platforms. Move the DLSUFFIX assignment from src/makefiles/ to src/templates/, have configure read it, and then substitute it into Makefile.global and pg_config.h. This avoids the need for all makefile rules that need it to locally set CPPFLAGS. It also resolves an inconsistent setup between the two Windows build systems. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/2f9861fb-8969-9005-7518-b8e60f2bead9@enterprisedb.com
* Fix collection of typos in the code and the documentationMichael Paquier2022-03-151-1/+1
| | | | | | | | Some words were duplicated while other places were grammatically incorrect, including one variable name in the code. Author: Otto Kekalainen, Justin Pryzby Discussion: https://postgr.es/m/7DDBEFC5-09B6-4325-B942-B563D1A24BDC@amazon.com
* Ensure the right perl is used for TAP tests on msysAndrew Dunstan2022-02-201-0/+5
| | | | | | | | | In particular, perl with $Config{osname} = msys should only be used if the build target is msys (which is currently buildable but not usable). For builds targeted at native Windows, perl from the ucrt64 toolchain is suitable. Discussion: https://postgr.es/m/20220216210141.5glt5isg5qtwty4c@alap3.anarazel.de
* Suppress warning about stack_base_ptr with late-model GCC.Tom Lane2022-02-171-0/+22
| | | | | | | | | | | | | | | | | | | | GCC 12 complains that set_stack_base is storing the address of a local variable in a long-lived pointer. This is an entirely reasonable warning (indeed, it just helped us find a bug); but that behavior is intentional here. We can work around it by using __builtin_frame_address(0) instead of a specific local variable; that produces an address a dozen or so bytes different, in my testing, but we don't care about such a small difference. Maybe someday a compiler lacking that function will start to issue a similar warning, but we'll worry about that when it happens. Patch by me, per a suggestion from Andres Freund. Back-patch to v12, which is as far back as the patch will go without some pain. (Recently-established project policy would permit a back-patch as far as 9.2, but I'm disinclined to expend the work until GCC 12 is much more widespread.) Discussion: https://postgr.es/m/3773792.1645141467@sss.pgh.pa.us
* plpython: Reject Python 2 during build configuration.Andres Freund2022-02-161-3/+6
| | | | | | | | | | | | | | Python 2.7 went EOL 2020-01-01 and the support for Python 2 requires a fair bit of infrastructure. Therefore we are removing Python 2 support in plpython. This patch just rejects Python 2 during configure / mkvcbuild.pl. Future commits will remove the code and infrastructure for Python 2 support and adjust more of the documentation. This way we can see the buildfarm state after the removal sooner and we can be sure that failures are due to desupporting Python 2, rather than caused by infrastructure cleanup. Reviewed-By: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/20211031184548.g4sxfe47n2kyi55r@alap3.anarazel.de
* Remove configure's check for rl_completion_append_character.Tom Lane2022-02-021-20/+2
| | | | | | | | | | | | | | | The comment for PGAC_READLINE_VARIABLES says "Readline versions < 2.1 don't have rl_completion_append_character". It seems certain that such versions are extinct in the wild, though; for sure there are none in the buildfarm. Libedit has had this variable for at least twenty years too. Also, tab-complete.c's behavior without it is quite unfriendly, since we'll emit a space even when completion fails; but we've had no complaints about that. Therefore, let's assume this variable is always there, and drop the configure check to save a few build cycles. Discussion: https://postgr.es/m/147685.1643858911@sss.pgh.pa.us
* Replace use of deprecated Python module distutils.sysconfig, take 2.Tom Lane2022-01-251-20/+13
| | | | | | | | | | | | | | | | | | | | With Python 3.10, configure spits out warnings about the module distutils.sysconfig being deprecated and scheduled for removal in Python 3.12. Change the uses in configure to use the module sysconfig instead. The logic stays largely the same, although we have to rely on INCLUDEPY instead of the deprecated get_python_inc function. Note that sysconfig exists since Python 2.7, so this moves the minimum required version up from Python 2.6. Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x version is now 3.2. We should consider back-patching this if it gives no further trouble, as the no-longer-supported versions are old enough to probably not be interesting to anyone. Peter Eisentraut, Tom Lane, Andres Freund Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
* Revert "Temporarily add some information about python include paths to ↵Tom Lane2022-01-251-21/+0
| | | | | | | configure." This reverts commit f032f63e727c1ab07603b3d1cd88d50f850d5738. We don't need it anymore.
* Temporarily add some information about python include paths to configure.Andres Freund2022-01-231-0/+21
| | | | | | | | | | We're still (see e0e567a1067, e0e567a1067) working on replacing use of the deprecated distutils. This commit just makes configure print out the results of different ways of determining the include path. Hopefully this will help us to find a way to transition away from distutils without turning the buildfarm red for prolonged amounts of time. Discussion: https://postgr.es/m/20220124025301.qu36x44w6m67cnap@alap3.anarazel.de
* Revert "Make configure prefer python3 to plain python."Tom Lane2022-01-201-5/+7
| | | | | | | | This reverts commit f201da39edcd6ac1ab9a3edf3e20e2a73bbbe69e. The buildfarm is not ready for python3, evidently, so we'll give the owners some more time to get set up. Discussion: https://postgr.es/m/2872c9a0-4b0a-1354-d5f6-94d6f85ba354@enterprisedb.com
* Make configure prefer python3 to plain python.Tom Lane2022-01-191-7/+5
| | | | | | | | | | | | | This avoids possibly selecting Python 2.x on systems that have both Python 2 and Python 3. We used to feel that what "python" links to is a user choice that we should honor. However, we're about to cease support for Python 2, so users will no longer have any choice of that sort. This small change is being made ahead of the big Python-2-ectomy so that we can see how much of the buildfarm is not yet prepared for that. Systems with only Python 2 will continue to build that way, for now. Discussion: https://postgr.es/m/2872c9a0-4b0a-1354-d5f6-94d6f85ba354@enterprisedb.com
* Revert "Replace use of deprecated Python module distutils.sysconfig"Peter Eisentraut2022-01-181-14/+14
| | | | | | | | This reverts commit e0e567a106726f6709601ee7cffe73eb6da8084e. On various platforms, the new approach using the sysconfig module reported incorrect values for the include directory, and so any Python-related compilations failed. Revert for now and revisit later.
* Replace use of deprecated Python module distutils.sysconfigPeter Eisentraut2022-01-181-14/+14
| | | | | | | | | | | | With Python 3.10, configure spits out warnings about the module distutils.sysconfig being deprecated and scheduled for removal in Python 3.12. Change the uses in configure to use the module sysconfig instead. The logic stays the same. Note that sysconfig exists since Python 2.7, so this moves the minimum required version up from Python 2.6. Discussion: https://www.postgresql.org/message-id/flat/c74add3c-09c4-a9dd-1a03-a846e5b2fc52%40enterprisedb.com
* Pacify perlcritic.Tom Lane2021-11-221-0/+3
| | | | Per buildfarm.
* Probe $PROVE not $PERL while checking for modules needed by TAP tests.Tom Lane2021-11-222-77/+20
| | | | | | | | | | | | | | | | | | | Normally "prove" and "perl" come from the same Perl installation, but we support the case where they don't (mainly because the MSys buildfarm animals need this). In that case, AX_PROG_PERL_MODULES is completely the wrong thing to use, because it's checking what "perl" has. Instead, make a little TAP test script including the required modules, and run that under "prove". We don't need ax_prog_perl_modules.m4 at all after this change, so remove it. Back-patch to all supported branches, for the buildfarm's benefit. (In v10, this also back-patches the effects of commit 264eb03aa.) Andrew Dunstan and Tom Lane, per an observation by Noah Misch Discussion: https://postgr.es/m/E1moZHS-0002Cu-Ei@gemulon.postgresql.org
* Report found versions of required perl modulesAndrew Dunstan2021-11-121-2/+2
| | | | | | | | | | Configure tests for the presence of perl modules required for TAP tests, and that they meet specified minimum version requirements. This patch makes it report the version of the module that's actually found rather than just an 'ok' message. This will help in deciding if we can upgrade minimum requirements for these modules. Discussion: https://postgr.es/m/f5e1d308-4e33-37a7-bdf1-f6e0c75119de@dunslane.net
* Remove check for accept() argument typesPeter Eisentraut2021-11-091-78/+0
| | | | | | | | | | | This check was used to accommodate a staggering variety in particular in the type of the third argument of accept(). This is no longer of concern on currently supported systems. We can just use socklen_t in the code and put in a simple check that substitutes int for socklen_t if it's missing, to cover the few stragglers. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/3538f4c4-1886-64f2-dcff-aaad8267fb82@enterprisedb.com
* Adjust configure to insist on Perl version >= 5.8.3.Tom Lane2021-10-071-2/+2
| | | | | | | | | | | | | | | | Previously it only checked for version >= 5.8.0, although the documentation has said that the minimum version is 5.8.3 since commit dea6ba939. Per the discussion leading up to that commit, I (tgl) left it that way intentionally because you could, at the time, do some bare-bones stuff with 5.8.0. But we aren't actually testing against anything older than 5.8.3, so who knows if that's still true. It's pretty unlikely that anyone would care anyway, so let's just make configure's version check match the docs. Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87y278s6iq.fsf@wibble.ilmari.org Discussion: https://postgr.es/m/16894.1501392088@sss.pgh.pa.us
* Remove configure-time thread safety checking (thread_test.c).Tom Lane2021-07-241-433/+0
| | | | | | | | | | | | | | This testing was useful when it was written, nigh twenty years ago, but it seems fairly pointless for any platform built in the last dozen or more years. (Compare also the comments at 8a2121185.) Also we now have reports that the test program itself fails under ThreadSanitizer. Rather than invest effort in fixing it, let's just drop it, and assume that the few people who still care already know they need to use --disable-thread-safety. Back-patch into v14, for consistency with 8a2121185. Discussion: https://postgr.es/m/CADhDkKzPSiNvA3Hyq+wSR_icuPmazG0cFe=YnC3U-CFcYLc8Xw@mail.gmail.com
* Portability fixes for sigwait.Thomas Munro2021-07-151-4/+0
| | | | | | | | | | | | | | | | Build farm animals running ancient HPUX and Solaris have a non-standard sigwait() from draft versions of POSIX, so they didn't like commit 7c09d279. To avoid the problem in general, only try to use sigwait() if it's declared by <signal.h> and matches the expected declaration. To select the modern declaration on Solaris (even in non-threaded programs), move -D_POSIX_PTHREAD_SEMANTICS into the right place to affect all translation units. Also fix the error checking. Modern sigwait() doesn't set errno. Thanks to Tom Lane for help with this. Discussion: https://postgr.es/m/3187588.1626136248%40sss.pgh.pa.us
* Update config.guess and config.subPeter Eisentraut2021-04-212-414/+507
|
* Update copyright for 2021Bruce Momjian2021-01-021-1/+1
| | | | Backpatch-through: 9.5
* jit: configure: Explicitly reference 'native' component.Andres Freund2020-12-071-0/+1
| | | | | | | | | | | | | Until recently 'native' was implicitly included via 'orcjit', but a change included in LLVM 11 (not yet released) removed a number of such indirect component references. Reported-By: Fabien COELHO <coelho@cri.ensmp.fr> Reported-By: Andres Freund <andres@anarazel.de> Reported-By: Thomas Munro <thomas.munro@gmail.com> Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20201201064949.mex6kvi2kygby3ni@alap3.anarazel.de Backpatch: 11-, where jit support was added
* Remove configure-time probe for DocBook DTD.Tom Lane2020-11-301-40/+0
| | | | | | | | | | | | | | | | | | | | | | 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
* Remove the option to build thread_test.c outside configure.Tom Lane2020-10-211-0/+437
| | | | | | | | | | | | | | | | | | | Theoretically one could go into src/test/thread and build/run this program there. In practice, that hasn't worked since 96bf88d52, and probably much longer on some platforms (likely including just the sort of hoary leftovers where this test might be of interest). While it wouldn't be too hard to repair the breakage, the fact that nobody has noticed for two years shows that there is zero usefulness in maintaining this build pathway. Let's get rid of it and decree that thread_test.c is *only* meant to be built/used in configure. Given that decision, it makes sense to put thread_test.c under config/ and get rid of src/test/thread altogether, so that's what I did. In passing, update src/test/README, which had been ignored by some not-so-recent additions of subdirectories. Discussion: https://postgr.es/m/227659.1603041612@sss.pgh.pa.us
* Rename configure.in to configure.acPeter Eisentraut2020-07-241-1/+1
| | | | | | | The new name has been preferred by Autoconf for a long time. Future versions of Autoconf will warn about the old name. Discussion: https://www.postgresql.org/message-id/flat/e796c185-5ece-8569-248f-dd3799701be1%402ndquadrant.com
* Update config.guess and config.subPeter Eisentraut2020-04-302-60/+84
|
* Sync up some inconsistent comments in config/c-compiler.m4.Tom Lane2020-04-221-18/+18
| | | | | | | | | | | | | | | | | | Make header/trailer comments agree with the actual names of some macros. These seem like legit names in earlier iterations of respective patches (commit b779168ff "Detect PG_PRINTF_ATTRIBUTE automatically." and commit 6869b4f25 "Add C++ support to configure.") but the macro had been renamed out of sync with the header / trailer comment in the final committed patch. Even more nitpickily, make the dashed underlines agree with the lengths of the macro names everyplace. There doesn't seem to have been any meeting of the minds previously on whether those should match or not, but at least some people have been trying to make 'em match. Jesse Zhang, Tom Lane Discussion: https://postgr.es/m/CAGf+fX7DDyq6WfCy6X_KtD28MkbNBE6NkRi26fSf25dfUwX0zw@mail.gmail.com
* Enable Unix-domain sockets support on WindowsPeter Eisentraut2020-03-281-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As of Windows 10 version 1803, Unix-domain sockets are supported on Windows. But it's not automatically detected by configure because it looks for struct sockaddr_un and Windows doesn't define that. So we just make our own definition on Windows and override the configure result. Set DEFAULT_PGSOCKET_DIR to empty on Windows so by default no Unix-domain socket is used, because there is no good standard location. In pg_upgrade, we have to do some extra tweaking to preserve the existing behavior of not using Unix-domain sockets on Windows. Adding support would be desirable, but it needs further work, in particular a way to select whether to use Unix-domain sockets from the command-line or with a run-time test. The pg_upgrade test script needs a fix. The previous code passed "localhost" to postgres -k, which only happened to work because Windows used to ignore the -k argument value altogether. We instead need to pass an empty string to get the desired effect. The test suites will continue to not use Unix-domain sockets on Windows. This requires a small tweak in pg_regress.c. The TAP tests don't need to be changed because they decide by the operating system rather than HAVE_UNIX_SOCKETS. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com
View Lorry Controller Status