Bug 244225 - databases/postgresql12-server: fix build on GCC architectures
Summary: databases/postgresql12-server: fix build on GCC architectures
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: pgsql
Keywords: buildisok
Depends on:
Reported: 2020-02-19 09:54 UTC by Piotr Kubaj
Modified: 2020-03-29 20:36 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (pgsql)

patch (940 bytes, patch)
2020-02-19 09:54 UTC, Piotr Kubaj
no flags Details | Diff
v2 (611 bytes, patch)
2020-02-19 10:30 UTC, Piotr Kubaj
pkubaj: maintainer-approval? (pgsql)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kubaj freebsd_committer 2020-02-19 09:54:53 UTC
Created attachment 211758 [details]

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.
Comment 1 andrew 2020-02-19 10:04:10 UTC
Do you know why gcc is used for the i386 build?

If not, leave it alone.
Comment 2 Piotr Kubaj freebsd_committer 2020-02-19 10:09:20 UTC
(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.
Comment 3 Piotr Kubaj freebsd_committer 2020-02-19 10:30:31 UTC
Created attachment 211759 [details]

Is that ok?
Comment 4 andrew 2020-02-19 10:46:57 UTC
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.
Comment 5 andrew 2020-02-19 11:05:54 UTC
(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.)
Comment 6 Palle Girgensohn freebsd_committer 2020-02-19 22:18:47 UTC

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?
Comment 7 andrew 2020-02-20 04:22:12 UTC
(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.
Comment 8 Piotr Kubaj freebsd_committer 2020-02-20 08:34:29 UTC
(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=
Comment 9 andrew 2020-02-20 09:09:50 UTC
(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.)
Comment 10 Automation User 2020-03-06 00:15:17 UTC
Build info is available at https://gitlab.com/swills/freebsd-ports/pipelines/123770914
Comment 11 commit-hook freebsd_committer 2020-03-06 10:12:46 UTC
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

  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)

Comment 12 commit-hook freebsd_committer 2020-03-06 10:15:47 UTC
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

  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)

_U  branches/2020Q1/
Comment 13 commit-hook freebsd_committer 2020-03-29 20:36:31 UTC
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

  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

  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:


  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)

_U  branches/2020Q1/