summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2024-02-28Remove configure --with-CC optionHeikki Linnakangas
It's been deprecated since commit cb292206c5 from July 2000. Discussion: https://www.postgresql.org/message-id/a2a0f5d8-2d80-48e5-b8f7-0a0a6018c3b7@iki.fi
2024-02-28Remove AIX supportHeikki Linnakangas
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-11Fix gai_strerror() thread-safety on Windows.Thomas Munro
Commit 5579388d removed code that supplied a fallback implementation of getaddrinfo(), which was dead code on modern systems. One tiny piece of the removed code was still doing something useful on Windows, though: that OS's own gai_strerror()/gai_strerrorA() function returns a pointer to a static buffer that it overwrites each time, so it's not thread-safe. In rare circumstances, a multi-threaded client program could get an incorrect or corrupted error message. Restore the replacement gai_strerror() function, though now that it's only for Windows we can put it into a win32-specific file and cut it down to the errors that Windows documents. The error messages here are taken from FreeBSD, because Windows' own messages seemed too verbose. Back-patch to 16. Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/CA%2BhUKGKz%2BF9d2PTiXwfYV7qJw%2BWg2jzACgSDgPizUw7UG%3Di58A%40mail.gmail.com
2024-01-22Add backend support for injection pointsMichael Paquier
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-04Update copyright for 2024Bruce Momjian
Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZZKTDPxBBMt3C0J9@paquier.xyz Backpatch-through: 12
2023-11-29Optimize pg_readv/pg_pwritev single vector case.Thomas Munro
For the trivial case of iovcnt == 1, kernels are measurably slower at dealing with the more complex arguments of preadv/pwritev than the equivalent plain old pread/pwrite. The overheads are worth it for iovcnt > 1, but for 1 let's just redirect to the cheaper calls. While we could leave it to callers to worry about that, we already have to have our own pg_ wrappers for portability reasons so it seems reasonable to centralize this knowledge there (thanks to Heikki for this suggestion). Try to avoid function call overheads by making them inlinable, which might also allow the compiler to avoid the branch in some cases. For systems that don't have preadv and pwritev (currently: Windows and [closed] Solaris), we might as well pull the replacement functions up into the static inline functions too. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6uT5TUm2gkvA@mail.gmail.com
2023-11-28Use BIO_{get,set}_app_data instead of BIO_{get,set}_data.Tom Lane
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-10-25Log OpenSSL version in ./configure outputMichael Paquier
This information is useful to know when scanning buildfarm results, and it is already displayed in Meson. The output of `openssl version` is logged, with the command retrieved from PATH. This depends on c8e4030d1bdd, so backpatch down to 16. Reviewed-by: Peter Eisentraut, Daniel Gustafsson, Tom Lane Discussion: https://postgr.es/m/ZTW9yOlZaSVoFhTz@paquier.xyz Backpatch-through: 16
2023-08-17Remove traces of Sun -lposix4.Thomas Munro
This was a library on ancient Solaris systems, which was eventually replaced by -lrt, itself now redundant on that OS. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tristan Partin <tristan@neon.tech> Discussion: https://postgr.es/m/CA%2BhUKGLLVx4drdvXats9PxH3eeB%2BE2NkJReJ%2BRGmaOpU%3D9rgEA%40mail.gmail.com
2023-08-17Don't probe extra libraries for fdatasync.Thomas Munro
Commit d2e15083 got rid of the main configure probe and HAVE_FDATASYNC macro, but we still searched -lrt and -lposix4 for old Solaris systems. It's in the C library on modern Solaris, as on other supported systems. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tristan Partin <tristan@neon.tech> Discussion: https://postgr.es/m/CA%2BhUKGLLVx4drdvXats9PxH3eeB%2BE2NkJReJ%2BRGmaOpU%3D9rgEA%40mail.gmail.com
2023-08-10Use native CRC instructions on 64-bit LoongArchJohn Naylor
As with the Intel and Arm CRC instructions, compiler intrinsics for them must be supported by the compiler. In contrast, no runtime check is needed. Aligned memory access is faster, so use the Arm coding as a model. YANG Xudong Discussion: https://postgr.es/m/b522a0c5-e3b2-99cc-6387-58134fb88cbe%40ymatrix.cn
2023-08-07Remove configure check for z_streampPeter Eisentraut
This is surely obsolete. zlib version 1.0.4, which includes z_streamp, was released 1996-07-24. When this check was put in in 2001 (19c97b8579), the commit was already labeling that release as ancient. Reviewed-by: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/33462926-bb1e-7cc9-8d92-d86318e8ed1d%40eisentraut.org
2023-07-11Remove --disable-thread-safety and related code.Thomas Munro
All supported computers have either POSIX or Windows threads, and we no longer have any automated testing of --disable-thread-safety. We define a vestigial ENABLE_THREAD_SAFETY macro to 1 in ecpg_config.h in case it is useful, but we no longer test it anywhere in PostgreSQL code, and associated dead code paths are removed. The Meson and perl-based Windows build scripts never had an equivalent build option. Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CA%2BhUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc%2BNBB2TkNsw%40mail.gmail.com
2023-07-09Rename port/thread.c to port/user.c.Thomas Munro
Historically this module dealt with thread-safety of system interfaces, but now all that's left is wrapper code for user name and home directory lookup. Arguably the Windows variants of this logic could be moved in here too, to justify its presence under port. For now, just tidy up some obsolete references to multi-threading, and give the file a meaningful name. Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CA%2BhUKGLtmexrpMtxBRLCVePqV_dtWG-ZsEbyPrYc%2BNBB2TkNsw%40mail.gmail.com
2023-07-07Fix some comments in ./configure and meson setup filesMichael Paquier
The comments referring to SSL_CTX_set_cert_cb() in ./configure and ./configure.ac were inconsistent, as `autoreconf -i` would show. While on it, fix a typo on a comment related to the same check in meson.build. Issue introduced in 8e278b6, that removed support for OpenSSL 1.0.1. Per offlist report from Thomas Munro.
2023-07-03Remove support for OpenSSL 1.0.1Michael Paquier
Here are some notes about this change: - As X509_get_signature_nid() should always exist (OpenSSL and LibreSSL), hence HAVE_X509_GET_SIGNATURE_NID is now gone. - OPENSSL_API_COMPAT is bumped to 0x10002000L. - One comment related to 1.0.1e introduced by 74242c2 is removed. Upstream OpenSSL still provides long-term support for 1.0.2 in a closed fashion, so removing it is out of scope for a few years, at least. Reviewed-by: Jacob Champion, Daniel Gustafsson Discussion: https://postgr.es/m/ZG3JNursG69dz1lr@paquier.xyz
2023-06-29Stamp HEAD as 17devel.Tom Lane
Let the hacking begin ...
2023-06-26Stamp 16beta2.REL_16_BETA2Tom Lane
2023-05-22Stamp 16beta1.REL_16_BETA1Tom Lane
2023-04-18Build ICU support by default.Jeff Davis
Discussion: https://postgr.es/m/82c4c816-06f6-d3e3-ba02-fca4a5cef065%40enterprisedb.com Reviewed-by: Peter Eisentraut
2023-04-17Update Kerberos/GSSAPI configure/meson checkStephen Frost
Instead of checking for the much older gss_init_sec_context, check for gss_store_cred_into which was added in MIT Kerberos 1.11 (circa 2012). Discussion: https://postgr.es/m/2313469.1681695223%40sss.pgh.pa.us
2023-04-13Explicitly require MIT Kerberos for GSSAPIStephen Frost
WHen building with GSSAPI support, explicitly require MIT Kerberos and check for gssapi_ext.h in configure.ac and meson.build. Also add documentation explicitly stating that we now require MIT Kerberos when building with GSSAPI support. Reveiwed by: Johnathan Katz Discussion: https://postgr.es/m/abcc73d0-acf7-6896-e0dc-f5bc12a61bb1@postgresql.org
2023-04-12Fix detection of unseekable files for fseek() and ftello() with MSVCMichael Paquier
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-03-24libpq: Add sslcertmode option to control client certificatesMichael Paquier
The sslcertmode option controls whether the server is allowed and/or required to request a certificate from the client. There are three modes: - "allow" is the default and follows the current behavior, where a configured client certificate is sent if the server requests one (via one of its default locations or sslcert). With the current implementation, will happen whenever TLS is negotiated. - "disable" causes the client to refuse to send a client certificate even if sslcert is configured or if a client certificate is available in one of its default locations. - "require" causes the client to fail if a client certificate is never sent and the server opens a connection anyway. This doesn't add any additional security, since there is no guarantee that the server is validating the certificate correctly, but it may helpful to troubleshoot more complicated TLS setups. sslcertmode=require requires SSL_CTX_set_cert_cb(), available since OpenSSL 1.0.2. Note that LibreSSL does not include it. Using a connection parameter different than require_auth has come up as the simplest design because certificate authentication does not rely directly on any of the AUTH_REQ_* codes, and one may want to require a certificate to be sent in combination of a given authentication method, like SCRAM-SHA-256. TAP tests are added in src/test/ssl/, some of them relying on sslinfo to check if a certificate has been set. These are compatible across all the versions of OpenSSL supported on HEAD (currently down to 1.0.1). Author: Jacob Champion Reviewed-by: Aleksander Alekseev, Peter Eisentraut, David G. Johnston, Michael Paquier Discussion: https://postgr.es/m/9e5a8ccddb8355ea9fa4b75a1e3a9edc88a70cd3.camel@vmware.com
2023-03-17libpq: Remove code for SCM credential authenticationMichael Paquier
Support for SCM credential authentication has been removed in the backend in 9.1, and libpq has kept some code to handle it for compatibility. Commit be4585b, that did the cleanup of the backend code, has done so because the code was not really portable originally. And, as there are likely little chances that this is used these days, this removes the remaining code from libpq. An error will now be raised by libpq if attempting to connect to a server that returns AUTH_REQ_SCM_CREDS, instead. References to SCM credential authentication are removed from the protocol documentation. This removes some meson and configure checks. Author: Michael Paquier Reviewed-by: Tom Lane Discussion: https://postgr.es/m/ZBLH8a4otfqgd6Kn@paquier.xyz
2023-02-17Remove obsolete platforms from ps_status.c.Thomas Munro
Time to remove various code, comments and configure/meson probes relating to ancient BSD, SunOS, GNU/Hurd, IRIX, NeXT and Unixware. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CA%2BhUKGJMNGUAqf27WbckYFrM-Mavy0RKJvocfJU%3DJ2XcAZyv%2Bw%40mail.gmail.com
2023-02-15Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificatesMichael Paquier
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-01-02Update copyright for 2023Bruce Momjian
Backpatch-through: 11
2022-12-12Disable clang 16's -Wcast-function-type-strict.Thomas Munro
Clang 16 is still in development, but seawasp reveals that it has started warning about many of our casts of function pointers (those introduced by commit 1c27d16e, and some older ones). Disable the new warning for now, since otherwise buildfarm animal seawasp fails, and we have no current plans to change our strategy for these callback function types. May be back-patched with other Clang/LLVM 16 changes around release time. Discussion: https://postgr.es/m/CA%2BhUKGJvX%2BL3aMN84ksT-cGy08VHErRNip3nV-WmTx7f6Pqhyw%40mail.gmail.com
2022-12-08Add option to specify segment size in blocksAndres Freund
The tests don't have much coverage of segment related code, as we don't create large enough tables. To make it easier to test these paths, add a new option specifying the segment size in blocks. Set the new option to 6 blocks in one of the CI tasks. Smaller numbers currently fail one of the tests, for understandable reasons. While at it, fix some segment size related issues in the meson build. Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20221107171355.c23fzwanfzq2pmgt@awork3.anarazel.de
2022-12-07autoconf: Move export_dynamic determination to configureAndres Freund
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
2022-12-02autoconf: Don't AC_SUBST() LD in configureAndres Freund
The only use of $(LD) in Makefiles is for AIX, to generate the export file for the backend. We only support the system linker on AIX and we already hardcode the path to a number of other binaries. Removing LD substitution will simplify the upcoming meson PGXS compatibility. While at it, add a comment why -r is used. A subsequent commit will remove the determination of LD from configure as well. Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
2022-12-02autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32CAndres Freund
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
2022-10-20Make finding openssl program a configure or meson optionPeter Eisentraut
Various test suites use the "openssl" program as part of their setup. There isn't a way to override which openssl program is to be used, other than by fiddling with the path, perhaps. This has gotten increasingly problematic because different versions of openssl have different capabilities and do different things by default. This patch checks for an openssl binary in configure and meson setup, with appropriate ways to override it. This is similar to how "lz4" and "zstd" are handled, for example. The meson build system actually already did this, but the result was only used in some places. This is now applied more uniformly. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/dc638b75-a16a-007d-9e1c-d16ed6cf0ad2%40enterprisedb.com
2022-10-19Track LLVM 15 changes.Thomas Munro
Per https://llvm.org/docs/OpaquePointers.html, support for non-opaque pointers still exists and we can request that on our context. We have until LLVM 16 to move to opaque pointers, a much larger change. Back-patch to 11, where LLVM support arrived. Author: Thomas Munro <thomas.munro@gmail.com> Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CAMHz58Sf_xncdyqsekoVsNeKcruKootLtVH6cYXVhhUR1oKPCg%40mail.gmail.com
2022-10-07autoconf: Rely on ar supporting index creationAndres Freund
This way we don't need RANLIB anymore, making it a bit simpler for the meson build to generate Makefile.global for PGXS compatibility. FreeBSD, NetBSD, OpenBSD, the only platforms where we didn't use AROPT=crs, all have supported the 's' option for a long time. On macOS we ran ranlib after installing a static library. This was added a long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent macOS versions. This is removed now. Based on discussion with Tom, I left the 'touch' at the end of static libraries generation, added in 826eff57c4c, in place. While it looks like current versions of Apple's ar/ranlib don't need it, it was needed not too long ago. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6clig6@awork3.anarazel.de
2022-10-07Add -Wshadow=compatible-local to the standard compilation flagsDavid Rowley
Since cd4e8caaa, we've been able to build the source tree with -Wshadow=compatible-local without any warnings. Lots of work was done by Justin Pryzby and I (David) to get all our code to compile warning free with that flag. In that process, 2 bugs (16d69ec29 and af7d270dd) were discovered and fixed. Additionally, "git log --grep=shadow" shows that there is no shortage of other bugs that have been fixed over the years which were caused by variable shadowing. In light of the above, it seems very much worthwhile to add at least -Wshadow=compatible-local to our standard compilation flags. We *may* want to go further and take this to -Wshadow=local in the future, but we're not ready for that today, so let's add -Wshadow=compatible-local now to help make sure we don't introduce further local variable shadowing. Author: Andres Freund Discussion: https://postgr.es/m/20221006003920.6xlqaoccxwisza5k@awork3.anarazel.de
2022-09-22meson: Add initial version of meson based build systemAndres Freund
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-17Remove DLLTOOL, DLLWRAP from configure / Makefile.global.inAndres Freund
We got rid of the need for them in 4f5f485d10c and 846e91e0223. Discussion: https://postgr.es/m/20220915022626.5xx3ccgkzpkqw5mq@awork3.anarazel.de
2022-09-16aix: xlc: Use -Wl,-b,expfull for old compiler versionsAndres Freund
Unfortunately xlc 12.1 and earlier don't support -qvisibility. Therefore be7c15b194a doesn't suffice to make extension libraries work without the explicit mkldexport step removed in fe6a64a58ab. While 12.1 is EOL, there is some desire to leave buildfarm animals using it run a bit longer. But instead of adding back the complicated mkldexport step, we can use -Wl,-b,expfull to force all symbols to be exported. Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/2490844.1663123546@sss.pgh.pa.us
2022-09-10configure: Expand -fvisibility checks to more compilers, test for -qvisibilityAndres Freund
It looks like icc and sunpro both support -fvisibility=hidden and xlc supports -qvisibility=hidden. I tested this on AIX and solaris with their proprietary compilers as well as gcc, and with gcc or clang on freebsd, linux, macos, netbsd and openbsd. Apparently my prior commit fe6a64a58ab only works in combination with this patch. While I tried to test them separately, an unknown caching issue prevented me from noticing the problem. Per discussion with Tom Lane and buildfarm member hoverfly. Discussion: https://postgr.es/m/20220910052741.t7w7csyrggwus2ze%40awork3.anarazel.de Discussion: https://postgr.es/m/20220820174213.d574qde4ptwdzoqz@awork3.anarazel.de
2022-08-25Remove configure probe for sockaddr_in6 and require AF_INET6.Thomas Munro
SUSv3 <netinet/in.h> defines struct sockaddr_in6, and all targeted Unix systems have it. Windows has it in <ws2ipdef.h>. Remove the configure probe, the macro and a small amount of dead code. Also remove a mention of IPv6-less builds from the documentation, since there aren't any. This is similar to commits f5580882 and 077bf2f2 for Unix sockets. Even though AF_INET6 is an "optional" component of SUSv3, there are no known modern operating system without it, and it seems even less likely to be omitted from future systems than AF_UNIX. Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
2022-08-22Remove configure probes for sockaddr_storage members.Thomas Munro
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
2022-08-18Don't add HAVE_LDAP_H HAVE_WINLDAP_H to pg_config.hAndres Freund
They're not referenced, so we don't need them in in pg_config.h. Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: http://postgr.es/m/e0c44fb2-8b66-a4b9-b274-7ed3a1a0ab74@enterprisedb.com
2022-08-18Remove unused configure variable.Tom Lane
configure extracts TCL_SHLIB_LD_LIBS from tclConfig.sh, and puts the value into Makefile.global, but then we never use it anywhere. It looks like I removed the only usage in cd75f94da, but didn't notice that it was the only usage. Might as well mop this up while we're trying to get rid of unnecessary configure steps. Discussion: https://postgr.es/m/2442359.1660835043@sss.pgh.pa.us
2022-08-18Remove configure probe for netinet/tcp.h.Thomas Munro
<netinet/tcp.h> is in SUSv3 and all targeted Unix systems have it. For Windows, we can provide a stub include file, to avoid some #ifdef noise. Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
2022-08-18Remove configure probe for sys/sockio.h.Thomas Munro
On BSD-family systems, header <sys/sockio.h> defines socket ioctl numbers like SIOCGIFCONF. Only AIX is using those now, but it defines them in <net/if.h> anyway. Supposing some PostgreSQL hacker wants to test that AIX-only code path on a more common development system by pretending not to have getifaddrs(). It's enough to include <sys/ioctl.h>, at least on macOS, FreeBSD and Linux, and we're already doing that.
2022-08-18Remove configure probe for net/if.h.Thomas Munro
<net/if.h> is in SUSv3 and all targeted Unixes have it. It's used in a region that is already ifdef'd out for Windows. We're not using it for any standard definitions, but it's where AIX defines conventional socket ioctl numbers. Discussion: https://postgr.es/m/CA+hUKGKErNfhmvb_H0UprEmp4LPzGN06yR2_0tYikjzB-2ECMw@mail.gmail.com
2022-08-13Remove configure probe for gethostbyname_r.Thomas Munro
It was only used by src/port/getaddrinfo.c, removed by the previous commit. Discussion: https://postgr.es/m/CA%2BhUKGJFLPCtAC58EAimF6a6GPw30TU_59FUY%3DGWB_kC%3DJEmVQ%40mail.gmail.com
2022-08-13Remove replacement code for getaddrinfo.Thomas Munro
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