Created attachment 211758 [details] patch Don't enable LLVM option on GCC architectures. Since this will conflict with USES=compiler:gcc-c++11-lib, remove it. Port compiles cleanly on i386 anyway.
Do you know why gcc is used for the i386 build? If not, leave it alone.
(In reply to andrew from comment #1) I don't know but it wasn't explained in the commit message, so I assumed that the port didn't compile.
Created attachment 211759 [details] v2 Is that ok?
It doesn't compile on i386 unless _either_ you use gcc (or other compiler supporting -fexcess-precision=standard, which at least up to 9.x clang does not), _or_ you have -msse2 or a cpu/arch flag that implies sse2 (from memory, pentium4 or later, I'd have to check the exact version). This is explicitly checked in the ./configure script.
(In reply to Piotr Kubaj from comment #3) The logic seems plausible, but I'm not the maintainer (this one caught my eye by chance). (However, somewhat unrelated to this issue, I do see that the problem with gcc + i386 + sse (not sse2) is still unfixed, see bug #236025 and http://postgr.es/m/875zstb2hr.fsf@news-spur.riddles.org.uk That's really a toolchain bug specific to i386, not an issue with gcc architectures.)
https://www.mail-archive.com/freebsd-ports@freebsd.org/msg80270.html has some background to why we use GCC and not -msse2. The problem seems to be that we cannot use LLVM support with i386 at all? That's sad, since LLVM really adds a great feature, but I guess if it won't work it won't work?
(In reply to Palle Girgensohn from comment #6) To my knowledge there's nothing inherent in postgres, or gcc, or llvm that prevents JIT from working in a gcc build. But there are various ways that I believe the JIT build currently fails on freebsd: 1. When I last tested it on armv7 which was some time ago, JIT fails because of a whole load of missing intrinsics symbols, and it wasn't clear whether this should be fixed in LLVM, or in FreeBSD, or whether PG should just work around it. see http://postgr.es/m/87imxbgtm9.fsf@news-spur.riddles.org.uk 2. The stack alignment mismatch on i386 between gcc and llvm will very probably mean bus errors on some code paths that go from gcc-compiled code into JITed code and back into gcc-compiled code, if any SSE arch is selected (i.e. pentium3+). This in addition to the existing issue with bus errors in worker processes. If there are build failures with JIT on mips/ppc/sparc systems then it'd be useful to know what they are.
(In reply to andrew from comment #7) It fails on powerpc64 on 12.1-RELEASE: configure:5033: checking for LLVM_CONFIG configure:5035: result: /usr/local/bin/llvm-config90 configure:5061: checking for clang configure:5094: result: no configure:5061: checking for clang-7 configure:5094: result: no configure:5061: checking for clang-6.0 configure:5094: result: no configure:5061: checking for clang-5.0 configure:5094: result: no configure:5061: checking for clang-4.0 configure:5094: result: no configure:5061: checking for clang-3.9 configure:5094: result: no configure:5111: error: clang not found, but required when compiling --with-llvm, specify with CLANG=
(In reply to Piotr Kubaj from comment #8) That looks like it's wrong even on non-gcc architectures; CLANG and CXX need to be set in CONFIGURE_ENV, not just LLVM_CONFIG. (CC stays as it is. CC is used to build the server proper, CXX is used to build the jit/llvm files which are encapsulated into a separate .so which will be dynamically loaded, and CLANG is used to compile the bitcode files.)
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/123770914
A commit references this bug: Author: pkubaj Date: Fri Mar 6 10:12:19 UTC 2020 New revision: 527871 URL: https://svnweb.freebsd.org/changeset/ports/527871 Log: databases/postgresql12-server: fix build on GCC architectures Use LLVM only if Clang is used. PR: 244225 Approved by: pgsql (maintainer timeout) MFH: 2020Q1 (fix build blanket) Changes: head/databases/postgresql12-server/Makefile
A commit references this bug: Author: pkubaj Date: Fri Mar 6 10:14:45 UTC 2020 New revision: 527872 URL: https://svnweb.freebsd.org/changeset/ports/527872 Log: MFH: r527871 databases/postgresql12-server: fix build on GCC architectures Use LLVM only if Clang is used. PR: 244225 Approved by: pgsql (maintainer timeout) Approved by: portmgr (fix build blanket) Changes: _U branches/2020Q1/ branches/2020Q1/databases/postgresql12-server/Makefile
A commit references this bug: Author: girgen Date: Sun Mar 29 19:58:17 UTC 2020 New revision: 529830 URL: https://svnweb.freebsd.org/changeset/ports/529830 Log: MFH: r526063 r527871 The PostgreSQL Global Development Group has released an update to all supported versions of our database system, including 12.2, 11.7, 10.12, 9.6.17, 9.5.21, and 9.4.26. This release fixes one security issue found in the PostgreSQL server and over 75 bugs reported over the last three months. Users should plan to update as soon as possible. PostgreSQL 9.4 Now EOL This is the last release for PostgreSQL 9.4, which will no longer receive security updates and bug fixes. PostgreSQL 9.4 introduced new features such as JSONB support, the `ALTER SYSTEM` command, the ability to stream logical changes to an output plugin, and more: https://www.postgresql.org/about/news/1557/ https://www.postgresql.org/docs/9.4/release-9-4.html While we are very proud of this release, these features are also found in newer versions of PostgreSQL. Many of these features have also received improvements, and, per our versioning policy, it is time to retire PostgreSQL 9.4. To receive continued support, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see the PostgreSQL versioning policy for more information. Security Issues * CVE-2020-1720: `ALTER ... DEPENDS ON EXTENSION` is missing authorization checks. Versions Affected: 9.6 - 12 The `ALTER ... DEPENDS ON EXTENSION` sub-commands do not perform authorization checks, which can allow an unprivileged user to drop any function, procedure, materialized view, index, or trigger under certain conditions. This attack is possible if an administrator has installed an extension and an unprivileged user can `CREATE`, or an extension owner either executes `DROP EXTENSION` predictably or can be convinced to execute `DROP EXTENSION`. Release notes: https://www.postgresql.org/docs/current/release.html databases/postgresql12-server: fix build on GCC architectures Use LLVM only if Clang is used. PR: 244225, 244985 Approved by: ports-secteam (joneum) Changes: _U branches/2020Q1/ branches/2020Q1/databases/postgresql10-server/Makefile branches/2020Q1/databases/postgresql10-server/distinfo branches/2020Q1/databases/postgresql11-server/Makefile branches/2020Q1/databases/postgresql11-server/distinfo branches/2020Q1/databases/postgresql12-server/Makefile branches/2020Q1/databases/postgresql12-server/distinfo branches/2020Q1/databases/postgresql12-server/pkg-plist-client branches/2020Q1/databases/postgresql12-server/pkg-plist-server branches/2020Q1/databases/postgresql94-server/Makefile branches/2020Q1/databases/postgresql94-server/distinfo branches/2020Q1/databases/postgresql95-server/Makefile branches/2020Q1/databases/postgresql95-server/distinfo branches/2020Q1/databases/postgresql96-server/Makefile branches/2020Q1/databases/postgresql96-server/distinfo