Обсуждение: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
От
PG Bug reporting form
Дата:
The following bug has been logged on the website: Bug reference: 18289 Logged by: John Fensterman Email address: john.fensterman@charter.com PostgreSQL version: 14.10 Operating system: Linux RHEL 8.6 Description: The postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm contains a deprecated clang option for opaque pointers. After installing the above package and attempting to install the temporal tables extension, which uses pgxs and the Makefile.global, the extension install will fail. As a test, I removed these specific entries and the extension will install without issue. Modifying clang flags with regards to opaque pointers appears to have been deprecated in 2023. Transition State As of July 2023: Typed pointers are not supported on the main branch. The following typed pointer functionality has been removed: The CLANG_ENABLE_OPAQUE_POINTERS cmake flag is no longer supported. The -no-opaque-pointers cc1 clang flag is no longer supported. The -opaque-pointers opt flag is no longer supported. The -plugin-opt=no-opaque-pointers LTO flag is no longer supported. C APIs that do not support opaque pointers (like LLVMBuildLoad) are no longer supported. The following typed pointer functionality is still to be removed: Various APIs that are no longer relevant with opaque pointers. Makefile.global entries impacted: BITCODE_CFLAGS = -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Xclang -no-opaque-pointers BITCODE_CXXFLAGS = -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Xclang -no-opaque-pointers -O2 Sample error when performing Make: make /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Xclang -no-opaque-pointers -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-deprecated-non-prototype -O2 -I. -I./ -I/usr/pgsql-14/include/server -I/usr/pgsql-14/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include -flto=thin -emit-llvm -c -o temporal_tables.bc temporal_tables.c error: unknown argument: '-no-opaque-pointers' make: *** [/usr/pgsql-14/lib/pgxs/src/makefiles/../../src/Makefile.global:1084: temporal_tables.bc] Error 1
On Sat, Jan 13, 2024 at 7:34 AM PG Bug reporting form <noreply@postgresql.org> wrote: > make > /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv > -fexcess-precision=standard -Xclang -no-opaque-pointers > -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro > -Wno-deprecated-non-prototype -O2 -I. -I./ -I/usr/pgsql-14/include/server > -I/usr/pgsql-14/include/internal -D_GNU_SOURCE -I/usr/include/libxml2 > -I/usr/include -flto=thin -emit-llvm -c -o temporal_tables.bc > temporal_tables.c > error: unknown argument: '-no-opaque-pointers' Which version of clang is that? And can you tell from any of the artefacts in that -devel package which version of clang was used when it was configured? LLVM 13-15 had optional opaque pointers, and LLVM 16+ required them. We only started using them when they were absolutely required, at the same time as we added support for LLVM 16. Since we weren't sure what might break if we changed the behaviour with already-released code, eg .bc files that might be part of an extension, we figured it would be best to keep using -no-opaque-pointers with older clangs that will accept it. There is a test in the configure script: checking whether /usr/bin/clang supports -Xclang -no-opaque-pointers, for BITCODE_CFLAGS... (cached) no checking whether /usr/bin/clang -xc++ supports -Xclang -no-opaque-pointers, for BITCODE_CXXFLAGS... (cached) no Now if the package maintainer 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?
Hi, On Sat, 2024-01-13 at 17:33 +1300, Thomas Munro wrote: > > Now if the package maintainer :) > 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? Cheers, -- Devrim Gündüz Open Source Solution Architect, PostgreSQL Major Contributor Twitter: @DevrimGunduz , @DevrimGunduzTR
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
Good morning Thomas.
These are the versions of clang and llvm that are being installed with the rpm in question:
postgresql.org/pub/repos/yum/14/redhat/rhel-8-x86_64/postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm
clang-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64
clang-devel-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64
clang-libs-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64
clang-resource-filesystem-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64
clang-tools-extra-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64
llvm-compat-libs-13.0.1-2.module_el8.7.0+1142+5343df54.x86_64
llvm-devel-17.0.2-2.module_el8+738+cd33199b.x86_64
llvm-googletest-17.0.2-2.module_el8+738+cd33199b.x86_64
llvm-libs-17.0.2-2.module_el8+738+cd33199b.x86_64
llvm-static-17.0.2-2.module_el8+738+cd33199b.x86_64
llvm-test-17.0.2-2.module_el8+738+cd33199b.x86_64
Here are the sandbox machines details, please let me know if I can provide any other information:
Linux 4.18.0-372.32.1.el8_6.x86_64 #1 SMP Fri Oct 7 12:35:10 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
Group: Development Tools
Description: A basic development environment.
Mandatory Packages:
autoconf
automake
binutils
bison
flex
gcc
gcc-c++
gdb
glibc-devel
libtool
make
pkgconf
pkgconf-m4
pkgconf-pkg-config
redhat-rpm-config
rpm-build
rpm-sign
strace
Default Packages:
asciidoc
byacc
ctags
diffstat
elfutils-libelf-devel
git
intltool
jna
ltrace
patchutils
perl-Fedora-VSP
perl-Sys-Syslog
perl-generators
pesign
source-highlight
systemtap
valgrind
valgrind-devel
Optional Packages:
cmake
expect
rpmdevtools
rpmlint
compiler-rt.x86_64 13.0.0-1.module_el8.6.0+1029+6594c364 @appstream
gcc.x86_64 8.5.0-21.el8 @baseos
gcc-c++.x86_64 8.5.0-21.el8 @appstream
gcc-gdb-plugin.x86_64 8.5.0-21.el8 @appstream
gcc-plugin-annobin.x86_64 8.5.0-21.el8 @baseos
gcc-toolset-13.x86_64 13.0-2.el8 @@commandline
gcc-toolset-13-annobin-docs.noarch 12.32-2.el8 @appstream
gcc-toolset-13-annobin-plugin-gcc.x86_64 12.32-2.el8 @appstream
gcc-toolset-13-binutils.x86_64 2.40-15.el8 @appstream
gcc-toolset-13-binutils-gold.x86_64 2.40-15.el8 @appstream
gcc-toolset-13-dwz.x86_64 0.14-0.el8 @appstream
gcc-toolset-13-gcc.x86_64 13.2.1-6.el8 @appstream
gcc-toolset-13-gcc-c++.x86_64 13.2.1-6.el8 @appstream
gcc-toolset-13-gcc-gfortran.x86_64 13.2.1-6.el8 @appstream
gcc-toolset-13-gdb.x86_64 12.1-4.el8 @appstream
gcc-toolset-13-libquadmath-devel.x86_64 13.2.1-6.el8 @appstream
gcc-toolset-13-libstdc++-devel.x86_64 13.2.1-6.el8 @appstream
gcc-toolset-13-runtime.x86_64 13.0-2.el8 @appstream
libgcc.x86_64 8.5.0-21.el8 @baseos
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.362.b08-3.el8 @appstream
javapackages-filesystem.noarch 5.3.0-2.module_el8.0.0+30+832da3a1 @powertools
tzdata-java.noarch 2023c-1.el8 @appstream
Installed Packages
gcc.x86_64 8.5.0-21.el8
@baseos
Installed Packages
gcc.x86_64
8.5.0-21.el8 @baseos
gcc-c++.x86_64
8.5.0-21.el8 @appstream
gcc-gdb-plugin.x86_64
8.5.0-21.el8 @appstream
gcc-plugin-annobin.x86_64
8.5.0-21.el8 @baseos
gcc-toolset-13.x86_64
13.0-2.el8 @@commandline
gcc-toolset-13-annobin-docs.noarch
12.32-2.el8 @appstream
gcc-toolset-13-annobin-plugin-gcc.x86_64
12.32-2.el8 @appstream
gcc-toolset-13-binutils.x86_64
2.40-15.el8 @appstream
gcc-toolset-13-binutils-gold.x86_64
2.40-15.el8 @appstream
gcc-toolset-13-dwz.x86_64
0.14-0.el8 @appstream
gcc-toolset-13-gcc.x86_64
13.2.1-6.el8 @appstream
gcc-toolset-13-gcc-c++.x86_64
13.2.1-6.el8 @appstream
gcc-toolset-13-gcc-gfortran.x86_64
13.2.1-6.el8 @appstream
gcc-toolset-13-gdb.x86_64
12.1-4.el8 @appstream
gcc-toolset-13-libquadmath-devel.x86_64
13.2.1-6.el8 @appstream
gcc-toolset-13-libstdc++-devel.x86_64
13.2.1-6.el8 @appstream
gcc-toolset-13-runtime.x86_64
13.0-2.el8 @appstream
-----Original Message-----
From: Thomas Munro <thomas.munro@gmail.com>
Sent: Friday, January 12, 2024 10:34 PM
To: Fensterman, John P <John.Fensterman@charter.com>; pgsql-bugs@lists.postgresql.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 Sat, Jan 13, 2024 at 7:34 AM PG Bug reporting form <noreply@postgresql.org> wrote:
> make
> /usr/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv
> -fexcess-precision=standard -Xclang -no-opaque-pointers
> -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro
> -Wno-deprecated-non-prototype -O2 -I. -I./
> -I/usr/pgsql-14/include/server -I/usr/pgsql-14/include/internal
> -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include -flto=thin
> -emit-llvm -c -o temporal_tables.bc temporal_tables.c
> error: unknown argument: '-no-opaque-pointers'
Which version of clang is that? And can you tell from any of the artefacts in that -devel package which version of
clangwas used when it was configured?
LLVM 13-15 had optional opaque pointers, and LLVM 16+ required them.
We only started using them when they were absolutely required, at the same time as we added support for LLVM 16. Since
weweren't sure what might break if we changed the behaviour with already-released code, eg .bc files that might be part
ofan extension, we figured it would be best to keep using -no-opaque-pointers with older clangs that will accept it.
Thereis a test in the configure script:
checking whether /usr/bin/clang supports -Xclang -no-opaque-pointers, for BITCODE_CFLAGS... (cached) no checking
whether/usr/bin/clang -xc++ supports -Xclang -no-opaque-pointers, for BITCODE_CXXFLAGS... (cached) no
Now if the package maintainer used a different major version of clang than you're using to compile your extension, it
mayhave some compiler flags that your compiler doesn't like. I guess that problem is more general than LLVM, though?
E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain
confidentialand/or legally privileged information. If you are not the intended recipient of this message or if this
messagehas been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this
messageand 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.
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 pointersflag to be set. When our DBA downgraded from llvm17 to llvm16 we were able to install w/o issue. TLDR: the 14.10 devel rpm (.../14/redhat/rhel-8-x86_64/postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm) contains llvm17 anddowngrading to v16 bypasses the failure. John Fensterman | Data Architect -----Original Message----- From: Jeremy Schneider <schneider@ardentperf.com> Sent: Tuesday, January 16, 2024 10:00 AM To: Devrim Gündüz <devrim@gunduz.org>; Thomas Munro <thomas.munro@gmail.com>; Fensterman, John P <John.Fensterman@charter.com>;pgsql-bugs@lists.postgresql.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 & availableas an RPM. I'd think we wouldn't need to rebuild extensions that are available as RPMs. Isn't the problem basically that PGXS preservesall the compiler settings in Makefile.global that were used to build Postgres on the build machine, and that someonewho 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 removethe 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 confidentialand/or legally privileged information. If you are not the intended recipient of this message or if this messagehas been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this messageand 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.
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@ardentperf.com>; Devrim Gündüz <devrim@gunduz.org>; Thomas Munro <thomas.munro@gmail.com>;pgsql-bugs@lists.postgresql.org Subject: RE: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option inMakefile.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 pointersflag 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 anddowngrading to v16 bypasses the failure. John Fensterman | Data Architect -----Original Message----- From: Jeremy Schneider <schneider@ardentperf.com> Sent: Tuesday, January 16, 2024 10:00 AM To: Devrim Gündüz <devrim@gunduz.org>; Thomas Munro <thomas.munro@gmail.com>; Fensterman, John P <John.Fensterman@charter.com>;pgsql-bugs@lists.postgresql.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 & availableas an RPM. I'd think we wouldn't need to rebuild extensions that are available as RPMs. Isn't the problem basically that PGXS preservesall the compiler settings in Makefile.global that were used to build Postgres on the build machine, and that someonewho 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 removethe 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 confidentialand/or legally privileged information. If you are not the intended recipient of this message or if this messagehas been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this messageand 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.
Hi, On Tue, 2024-01-16 at 17:42 +0000, Fensterman, John P wrote: > These are the versions of clang and llvm that are being installed with > the rpm in question: > postgresql.org/pub/repos/yum/14/redhat/rhel-8-x86_64/postgresql14- > devel-14.10-2PGDG.rhel8.x86_64.rpm > > clang-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-devel-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-libs-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-resource-filesystem-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-tools-extra-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > > llvm-compat-libs-13.0.1-2.module_el8.7.0+1142+5343df54.x86_64 > llvm-devel-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-googletest-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-libs-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-static-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-test-17.0.2-2.module_el8+738+cd33199b.x86_64 I am confused. Where did you get LLVM 17 for RHEL 8? Latest RHEL 8 (8.9) has CLANG 15 and LLVM 16, so actually similar question applies to CLANG as well. All of our packages are built against LLVM and CLANG 16 on RHEL 8. That said, is this really a RHEL or some other clone? Regards, -- Devrim Gündüz Open Source Solution Architect, PostgreSQL Major Contributor Twitter: @DevrimGunduz , @DevrimGunduzTR
Hi, On Tue, 2024-01-16 at 07:59 -0800, Jeremy Schneider wrote: > My understanding is that the problem is with PGXS and the > temporal_tables extension, which is not already-built & available as > an RPM. Just pushed temporal_tables to RHEL 8 repos (for the records, all other distros had this package since September.) I applied a band aid to the spec file to enable RHEL 8 builds: https://git.postgresql.org/gitweb/?p=pgrpms.git;a=commit;h=1f9c63a835ad7d7e7d4ab5743745d63087c1fe23 Regards, -- Devrim Gündüz Open Source Solution Architect, PostgreSQL Major Contributor Twitter: @DevrimGunduz , @DevrimGunduzTR
GM. Thanks for checking on this and providing updates. After your last comment on "is this really rhel", I went digging into what was actually installing llvm. I incorrectly assumed it was in the rhel devel package, but its merely a dependency and being installed from codebuilder,or in our sandbox instance, centos's power tools. So it appears that the issue very well might be with centos's version of llvm and not the rhel devel package as originallythought. We are currently working on ways to get the rhel subscription manager open to our new environments to keep these types ofissues from occurring in the future. I'll update the issue with any details once we have this piece sorted. Thanks. John Fensterman | Data Architect -----Original Message----- From: Devrim Gündüz <devrim@gunduz.org> Sent: Thursday, January 18, 2024 5:58 PM To: Fensterman, John P <John.Fensterman@charter.com>; Thomas Munro <thomas.munro@gmail.com>; pgsql-bugs@lists.postgresql.org Subject: Re: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option inMakefile.global CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links,or following guidance. Hi, On Tue, 2024-01-16 at 17:42 +0000, Fensterman, John P wrote: > These are the versions of clang and llvm that are being installed with > the rpm in question: > postgresql.org/pub/repos/yum/14/redhat/rhel-8-x86_64/postgresql14- > devel-14.10-2PGDG.rhel8.x86_64.rpm > > clang-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-devel-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-libs-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-resource-filesystem-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > clang-tools-extra-13.0.0-3.module_el8.6.0+1074+380cef3f.x86_64 > > llvm-compat-libs-13.0.1-2.module_el8.7.0+1142+5343df54.x86_64 > llvm-devel-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-googletest-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-libs-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-static-17.0.2-2.module_el8+738+cd33199b.x86_64 > llvm-test-17.0.2-2.module_el8+738+cd33199b.x86_64 I am confused. Where did you get LLVM 17 for RHEL 8? Latest RHEL 8 (8.9) has CLANG 15 and LLVM 16, so actually similar questionapplies to CLANG as well. All of our packages are built against LLVM and CLANG 16 on RHEL 8. That said, is this really a RHEL or some other clone? Regards, -- Devrim Gündüz Open Source Solution Architect, PostgreSQL Major Contributor Twitter: @DevrimGunduz , @DevrimGunduzTR E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidentialand/or legally privileged information. If you are not the intended recipient of this message or if this messagehas been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this messageand 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.