RE: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global

Sorry, copied the original package instead of the new one.
This was the package tested:
postgresql15-devel-15.5-2PGDG.rhel8.x86_64.rpm

Updated in below text as well.

John Fensterman | Data Architect

-----Original Message-----
From: Fensterman, John P
Sent: Thursday, January 18, 2024 3:13 PM
To: Jeremy Schneider <schneider(at)ardentperf(dot)com>; Devrim Gündüz <devrim(at)gunduz(dot)org>; Thomas Munro <thomas(dot)munro(at)gmail(dot)com>; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: RE: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global

Quick follow up:

Our DBA was testing a fresh install of pg 15.
It failed when he attempted to install temporal tables and mysql (mostly expected).

We scrutinized the versions of llvm and cLang and re-read the llvm versions and changes website.

llvm17 has the makefile issue as the xClang option is deprecated but not in llvm16 as v16 still allowed the opaque pointers flag to be set.

When our DBA downgraded from llvm17 to llvm16 we were able to install w/o issue.

TLDR: the 15..5 devel rpm (.../15/redhat/rhel-8-x86_64/ postgresql15-devel-15.5-2PGDG.rhel8.x86_64.rpm) contains llvm17 and downgrading to v16 bypasses the failure.

John Fensterman | Data Architect

-----Original Message-----
From: Jeremy Schneider <schneider(at)ardentperf(dot)com>
Sent: Tuesday, January 16, 2024 10:00 AM
To: Devrim Gündüz <devrim(at)gunduz(dot)org>; Thomas Munro <thomas(dot)munro(at)gmail(dot)com>; Fensterman, John P <John(dot)Fensterman(at)charter(dot)com>; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.

On 1/15/24 7:23 AM, Devrim Gündüz wrote:
>> used a different major version of clang than you're using to compile
>> your extension, it may have some compiler flags that your compiler
>> doesn't like.  I guess that problem is more general than LLVM, though?
>
> Hmm, so does it mean that I need to rebuild (almost) every extension
> that has llvmjit subpackage each time when RHEL releases a new LLVM
> version?

I've been chatting w John over slack about this too, not closely involved but I've been trying to be helpful if I can

My understanding is that the problem is with PGXS and the temporal_tables extension, which is not already-built & available as an RPM.

I'd think we wouldn't need to rebuild extensions that are available as RPMs. Isn't the problem basically that PGXS preserves all the compiler settings in Makefile.global that were used to build Postgres on the build machine, and that someone who builds an extension later might not have a matching environment to that Postgres RPM build environment?

While it's far from ideal, I think the right short-term workaround for John is to manually edit Makefile.global to remove the problematic clang flags and hopefully this doesn't "void the warranty" when he builds the temporal tables extension, right?

(I assume temporal_tables is not available as a pre-built RPM)

-Jeremy

--
http://about.me/jeremy_schneider

E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.