pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
10+ messages / 5 participants
[nested] [flat]
* BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-12 17:57 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 10+ messages in thread
From: PG Bug reporting form @ 2024-01-12 17:57 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: john.fensterman@charter.com
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-13 04:33 Thomas Munro <thomas.munro@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 2 replies; 10+ messages in thread
From: Thomas Munro @ 2024-01-13 04:33 UTC (permalink / raw)
To: john.fensterman@charter.com; pgsql-bugs@lists.postgresql.org
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?
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-15 15:23 Devrim Gündüz <devrim@gunduz.org>
parent: Thomas Munro <thomas.munro@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Devrim Gündüz @ 2024-01-15 15:23 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; john.fensterman@charter.com; pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-16 15:59 Jeremy Schneider <schneider@ardentperf.com>
parent: Devrim Gündüz <devrim@gunduz.org>
0 siblings, 2 replies; 10+ messages in thread
From: Jeremy Schneider @ 2024-01-16 15:59 UTC (permalink / raw)
To: Devrim Gündüz <devrim@gunduz.org>; Thomas Munro <thomas.munro@gmail.com>; john.fensterman@charter.com; pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* RE: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-16 17:42 Fensterman, John P <John.Fensterman@charter.com>
parent: Thomas Munro <thomas.munro@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Fensterman, John P @ 2024-01-16 17:42 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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 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?
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.
^ permalink raw reply [nested|flat] 10+ messages in thread
* RE: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-18 21:13 Fensterman, John P <John.Fensterman@charter.com>
parent: Jeremy Schneider <schneider@ardentperf.com>
1 sibling, 1 reply; 10+ messages in thread
From: Fensterman, John P @ 2024-01-18 21:13 UTC (permalink / raw)
To: Jeremy Schneider <schneider@ardentperf.com>; Devrim Gündüz <devrim@gunduz.org>; Thomas Munro <thomas.munro@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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 14.10 devel rpm (.../14/redhat/rhel-8-x86_64/postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm) contains llvm17 and downgrading 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 & 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.
^ permalink raw reply [nested|flat] 10+ messages in thread
* RE: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-18 21:15 Fensterman, John P <John.Fensterman@charter.com>
parent: Fensterman, John P <John.Fensterman@charter.com>
0 siblings, 0 replies; 10+ messages in thread
From: Fensterman, John P @ 2024-01-18 21:15 UTC (permalink / raw)
To: Jeremy Schneider <schneider@ardentperf.com>; Devrim Gündüz <devrim@gunduz.org>; Thomas Munro <thomas.munro@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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 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@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 & 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.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-18 23:57 Devrim Gündüz <devrim@gunduz.org>
parent: Fensterman, John P <John.Fensterman@charter.com>
0 siblings, 1 reply; 10+ messages in thread
From: Devrim Gündüz @ 2024-01-18 23:57 UTC (permalink / raw)
To: Fensterman, John P <John.Fensterman@charter.com>; Thomas Munro <thomas.munro@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-18 23:59 Devrim Gündüz <devrim@gunduz.org>
parent: Jeremy Schneider <schneider@ardentperf.com>
1 sibling, 0 replies; 10+ messages in thread
From: Devrim Gündüz @ 2024-01-18 23:59 UTC (permalink / raw)
To: Jeremy Schneider <schneider@ardentperf.com>; Thomas Munro <thomas.munro@gmail.com>; john.fensterman@charter.com; pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* RE: [EXTERNAL] Re: BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global
@ 2024-01-22 15:07 Fensterman, John P <John.Fensterman@charter.com>
parent: Devrim Gündüz <devrim@gunduz.org>
0 siblings, 0 replies; 10+ messages in thread
From: Fensterman, John P @ 2024-01-22 15:07 UTC (permalink / raw)
To: Devrim Gündüz <devrim@gunduz.org>; Thomas Munro <thomas.munro@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
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 originally thought.
We are currently working on ways to get the rhel subscription manager open to our new environments to keep these types of issues 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 in Makefile.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 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
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.
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2024-01-22 15:07 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-01-12 17:57 BUG #18289: postgresql14-devel-14.10-2PGDG.rhel8.x86_64.rpm Contains invalid cLang option in Makefile.global PG Bug reporting form <noreply@postgresql.org>
2024-01-13 04:33 ` Thomas Munro <thomas.munro@gmail.com>
2024-01-15 15:23 ` Devrim Gündüz <devrim@gunduz.org>
2024-01-16 15:59 ` Jeremy Schneider <schneider@ardentperf.com>
2024-01-18 21:13 ` Fensterman, John P <John.Fensterman@charter.com>
2024-01-18 21:15 ` Fensterman, John P <John.Fensterman@charter.com>
2024-01-18 23:59 ` Devrim Gündüz <devrim@gunduz.org>
2024-01-16 17:42 ` Fensterman, John P <John.Fensterman@charter.com>
2024-01-18 23:57 ` Devrim Gündüz <devrim@gunduz.org>
2024-01-22 15:07 ` Fensterman, John P <John.Fensterman@charter.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox