12 Commits (master)

Author	SHA1	Message	Date
Tom Lane	4300d8b6a7	Don't put library-supplied -L/-I switches before user-supplied ones. ... For many optional libraries, we extract the -L and -l switches needed to link the library from a helper program such as llvm-config. In some cases we put the resulting -L switches into LDFLAGS ahead of -L switches specified via --with-libraries. That risks breaking the user's intention for --with-libraries. It's not such a problem if the library's -L switch points to a directory containing only that library, but on some platforms a library helper may "helpfully" offer a switch such as -L/usr/lib that points to a directory holding all standard libraries. If the user specified --with-libraries in hopes of overriding the standard build of some library, the -L/usr/lib switch prevents that from happening since it will come before the user-specified directory. To fix, avoid inserting these switches directly into LDFLAGS during configure, instead adding them to LIBDIRS or SHLIB_LINK. They will still eventually get added to LDFLAGS, but only after the switches coming from --with-libraries. The same problem exists for -I switches: those coming from --with-includes should appear before any coming from helper programs such as llvm-config. We have not heard field complaints about this case, but it seems certain that a user attempting to override a standard library could have issues. The changes for this go well beyond configure itself, however, because many Makefiles have occasion to manipulate CPPFLAGS to insert locally-desirable -I switches, and some of them got it wrong. The correct ordering is any -I switches pointing at within-the- source-tree-or-build-tree directories, then those from the tree-wide CPPFLAGS, then those from helper programs. There were several places that risked pulling in a system-supplied copy of libpq headers, for example, instead of the in-tree files. (Commit cb36f8ec2 fixed one instance of that a few months ago, but this exercise found more.) The Meson build scripts may or may not have any comparable problems, but I'll leave it to someone else to investigate that. Reported-by: Charles Samborski <demurgos@demurgos.net> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/70f2155f-27ca-4534-b33d-7750e20633d7@demurgos.net Backpatch-through: 13	1 month ago
Peter Eisentraut	972c2cd288	jit: Require at least LLVM 14, if enabled. ... Remove support for LLVM versions 10-13. The default on all non-EOL'd OSes represented in our build farm will be at least LLVM 14 when PostgreSQL 18 ships. Author: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/CA%2BhUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY%3DiA%40mail.gmail.com	12 months ago
Thomas Munro	4dd29b6833	jit: Remove {llvm-config,clang}-N configure probes. ... Previously we searched for llvm-config-N and clang-N as well as the unversioned names, and maintained a list of expected values of N. There doesn't seem to be any reason to think that the default llvm-config and clang won't be good enough, and if they aren't, they can be overridden with LLVM_CONFIG and CLANG, so let's stop maintaining that list. The list had not been updated since LLVM 7 with no complaints, so commit 820b5af73d probably should have just removed it when dropping support for 7, instead of trying to be helpful by bringing it up to date with recent version numbers. The Meson build system didn't have that, so no change there. Suggested-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/CA%2BhUKG%2BSOP-aR%3DYF_n0dtXGWeCy6x%2BCn-RMWURU5ySQdmeKW1Q%40mail.gmail.com	1 year ago
Thomas Munro	820b5af73d	jit: Require at least LLVM 10. ... Remove support for older LLVM versions. The default on common software distributions will be at least LLVM 10 when PostgreSQL 17 ships. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/CA%2BhUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY%3DiA%40mail.gmail.com	2 years ago
Thomas Munro	5e4dacb987	Log LLVM library version in configure output. ... When scanning build farm results, it's useful to be able to see which version is in use. For the Meson build system, this information was already displayed. Back-patch to all supported branches. Discussion: https://postgr.es/m/4022690.1697852728%40sss.pgh.pa.us	2 years ago
Andres Freund	9543f0861b	jit: configure: Explicitly reference 'native' component. ... 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	5 years ago
Peter Eisentraut	4446565d36	Use better comment marker in Autoconf input ... The comment marker "#" is copied to the output, so it's only appropriate for comments that make sense in the shell output. For comments about the Autoconf language, "dnl" should be used.	7 years ago
Tom Lane	640a4ba052	Postpone LLVM-related uses of AC_CHECK_DECLS. ... Calling AC_CHECK_DECLS before we've finished setting up the compiler's CFLAGS seems like a pretty risky proposition, especially now that the first use of that macro will result in a test to see whether the compiler gives warning or error for undeclared built-in functions. That answer could very easily get changed later than where PGAC_LLVM_SUPPORT is called; furthermore, it's hardly unlikely that flags such as -D_GNU_SOURCE could change visibility of declarations. Hence, be a little less cavalier about where to do LLVM-related tests. This results in v11 and HEAD doing the warning-or-error check at the same place in the script as older branches are doing it, which seems like a good thing. Per further thought about commits 0b59b0e8b and 16fbac39f.	7 years ago
Andres Freund	240d40db88	Detect LLVM 7 without specifying binaries explicitly. ... Before this commit LLVM 7 was supported, but only if one explicitly provided LLVM_CONFIG= and CLANG= paths. As LLVM 7 is the first version that includes our upstreamed debugging and profiling features, and as debian is planning to default to 7 due to wider architecture support, it seems good to support auto-detecting that version. Author: Christoph Berg Discussion: https://postgr.es/m/20180912124517.GD24584@msg.df7cb.de Backpatch: 11, where LLVM was introduced	7 years ago
Andres Freund	cb92520563	LLVMJIT: LLVMGetHostCPUFeatures now is upstream, use LLMV version if available. ... Noticed thanks to buildfarm animal seawasp. Author: Andres Freund Backpatch: v11-, where LLVM based JIT compliation was introduced.	7 years ago
Andres Freund	e9a9843e13	LLVMJIT: Adapt to API changes in gdb and perf support. ... During the work of upstreaming my previous patches for gdb and perf support the API changed. Adapt. Normally this wouldn't necessarily be something to backpatch, but the previous API wasn't upstream, and at least the gdb support is quite useful for debugging. Author: Andres Freund Backpatch: 11, where LLVM based JIT support was added.	7 years ago
Andres Freund	5b2526c838	Add configure infrastructure (--with-llvm) to enable LLVM support. ... LLVM will be used for *optional* Just-in-time compilation support. This commit just adds the configure infrastructure that detects LLVM. No documentation has been added for the --with-llvm flag, that'll be added after the actual supporting code has been added. Author: Andres Freund Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de	8 years ago