Decouple C++ support in Meson's PGXS from LLVM enablement

On Thu, 17 Apr 2025 at 03:57, Tristan Partin <tristan@partin.io> wrote:

I spent some time exploring the Meson build a bit, and I realized that
C++ support in PGXS is tied to LLVM enablement. Checking the autotools
build in the configure.ac script indicates that that is not the case for
it.

Thank you for looking into this. I didn't try the patch, but just
reading it it all looks sensible (although my meson knowledge is quite
limited). I assume you tried to build pg_duckdb with a Meson based PG
build containing this patch and pg_duckdb built correctly?

On Thu Apr 17, 2025 at 2:15 AM CDT, Jelte Fennema-Nio wrote:

On Thu, 17 Apr 2025 at 03:57, Tristan Partin <tristan@partin.io> wrote:

I spent some time exploring the Meson build a bit, and I realized that
C++ support in PGXS is tied to LLVM enablement. Checking the autotools
build in the configure.ac script indicates that that is not the case for
it.

Thank you for looking into this. I didn't try the patch, but just
reading it it all looks sensible (although my meson knowledge is quite
limited). I assume you tried to build pg_duckdb with a Meson based PG
build containing this patch and pg_duckdb built correctly?

I took some time to backpatch to 17 on my machine so that I could build
pg_duckdb, and indeed with the backpatch applied, pg_duckdb compiles
successfully.

I do however hit linker errors later, but that is unrelated to the
current patch discussion. I'll discuss them with you in a different
forum.

--
Tristan Partin
https://tristan.partin.io

On Wed Apr 16, 2025 at 8:57 PM CDT, Tristan Partin wrote:

Howdy folks,

While playing around with pg_duckdb[0], a Postgres extension written in
C++ which uses PGXS, I came across a strange build error:

std=c++17 -Wno-sign-compare...
/bin/sh: line 1: -Wno-sign-compare: command not found

I was very confused by the error, but reading the command line, it made
sense. After talking to Jelte off-list, he told me to try a Postgres
installation that had been built with autotools. Today, I finally had
a chance to try that tip, and building pg_duckdb succeeded.

I spent some time exploring the Meson build a bit, and I realized that
C++ support in PGXS is tied to LLVM enablement. Checking the autotools
build in the configure.ac script indicates that that is not the case for
it.

On master, C++ support looks like:

llvmopt = get_option('llvm')
llvm = not_found_dep
if add_languages('cpp', required: llvmopt, native: false)
llvm = dependency('llvm', version: '>=14', method: 'config-tool', required: llvmopt)
if llvm.found()

cdata.set('USE_LLVM', 1)

cpp = meson.get_compiler('cpp')

By default, the `llvm` option is disabled, which Meson takes to mean,
"do not check for C++ support". Thusly, add_languages() returns false.
In addition, every check for adding to cxxflags, et. al. is gated on
llvm.found(), which is always false for the `not_found_dep`. All this
considered, the Makefile.global of a Postgres build roughly looked like:

CXX =
CXXFLAGS =
...

This then accounts for the original pg_duckdb command line looking the
way that it did.

Attached is a patch which decouples C++ support in PGXS from LLVM for
a Meson-compiled Postgres.

[0]: https://github.com/duckdb/pg_duckdb

With PGConf NYC around the corner, I thought I would rebase the original
patch. Please find v2 attached, which applies on top of
b0fb2c6aa5a485e28210e13ae5536c1231b1261f[0]https://github.com/tristan957/postgres/commit/b0fb2c6aa5a485e28210e13ae5536c1231b1261f :D.

GitHub branch: https://github.com/tristan957/postgres/tree/meson-cpp

[0]: https://github.com/tristan957/postgres/commit/b0fb2c6aa5a485e28210e13ae5536c1231b1261f

--
Tristan Partin
https://tristan.partin.io

ne 2. 11. 2025 v 17:21 odesílatel Tristan Partin <tristan@partin.io> napsal:

Howdy folks,

While playing around with pg_duckdb[0], a Postgres extension written in
C++ which uses PGXS, I came across a strange build error:

std=c++17 -Wno-sign-compare...
/bin/sh: line 1: -Wno-sign-compare: command not found

I was very confused by the error, but reading the command line, it made
sense. After talking to Jelte off-list, he told me to try a Postgres
installation that had been built with autotools. Today, I finally had
a chance to try that tip, and building pg_duckdb succeeded.

I spent some time exploring the Meson build a bit, and I realized that
C++ support in PGXS is tied to LLVM enablement. Checking the autotools
build in the configure.ac script indicates that that is not the case for
it.

On master, C++ support looks like:

llvmopt = get_option('llvm')
llvm = not_found_dep
if add_languages('cpp', required: llvmopt, native: false)
llvm = dependency('llvm', version: '>=14', method: 'config-tool', required: llvmopt)
if llvm.found()

cdata.set('USE_LLVM', 1)

cpp = meson.get_compiler('cpp')

By default, the `llvm` option is disabled, which Meson takes to mean,
"do not check for C++ support". Thusly, add_languages() returns false.
In addition, every check for adding to cxxflags, et. al. is gated on
llvm.found(), which is always false for the `not_found_dep`. All this
considered, the Makefile.global of a Postgres build roughly looked like:

CXX =
CXXFLAGS =
...

Did local build and review. I can confirm it detects CXX properly with
llvm disabled. Tested with

meson setup "$BUILD_DIR" \
--prefix="$INSTALL_DIR" \
--buildtype=debug \
-Dcassert=true \
-Dllvm=disabled

pre-patch (resulting into empty CXX) and post-patch (properly assigned
"ccache c++" to CXX).

Hi Tristan, Andres, Jelte, and pgsql-hackers,

Thank you for the excellent work on decoupling C++ support in Meson from
LLVM

SUMMARY: v2 PATCH TESTED AND WORKS PERFECTLY

- Built PostgreSQL 19devel (current master) with Meson

- Config: -Dllvm=disabled -Dcpp_support=auto

- Before patch: CXX = (empty) → extension fails with shell error

- After patch: CXX = ccache c++ → extension builds successfully

- Tested with minimal C++ extension → cpp_test.so created

REPRODUCTION & FIX STEPS

1. git remote add tristan https://github.com/tristan957/postgres.git

git fetch tristan

git checkout -b meson-cpp tristan/meson-cpp

2. meson setup build-fixed .. -Dllvm=disabled -Dcpp_support=auto

meson compile && meson install

3. Built test C++ extension:

cd ~/cpp_test_ext && make clean && make

VERIFIED OUTPUT
$ grep -E "^(CXX|CXXFLAGS) =" build-fixed/src/Makefile.global

CXX = ccache c++

CXXFLAGS = -fno-strict-aliasing -fwrapv -Wall -g -O0 ...

$ ls -l ~/cpp_test_ext/*.so

-rwxr-xr-x 1 boss boss 21568 Nov 4 12:18
/home/boss/cpp_test_ext/cpp_test.so

Patch applies cleanly and works perfectly on 19devel.

While testing the C++ PGXS patch, I noticed a usability gap:

If no C++ compiler is installed (e.g., `g++` missing), Meson silently

proceeds with C++ disabled — users only discover the issue when extensions

like pg_duckdb fail with confusing build errors.

This patch adds a clear, single warning during configuration:

WARNING: No C++ compiler found on your system.

Extensions using C++ (e.g. pg_duckdb) will FAIL to build.

Install g++ or clang++ to enable C++ support.

- Only shown when `add_languages('cpp')` returns `false`

- No warning when C++ is available

- Tested on PostgreSQL 19devel (with and without `g++`)

Attached: `0001-meson-warn-when-no-C-compiler-is-found.patch`

Happy to revise if there are better ways to surface this — open to
suggestions!

Thanks again for the great work on Meson C++ support.

Best regards,

Lakshmi

On 28.09.25 23:16, Tristan Partin wrote:

Attached is a patch which decouples C++ support in PGXS from LLVM for
a Meson-compiled Postgres.

[0]: https://github.com/duckdb/pg_duckdb

With PGConf NYC around the corner, I thought I would rebase the original
patch. Please find v2 attached, which applies on top of
b0fb2c6aa5a485e28210e13ae5536c1231b1261f[0] :D.

This patch makes sense to me. But I wonder what the behavior should be
if no C++ compiler is found. Because then you're back to the state
you're started from, with the confusing make error. If you imagine a
packager building postgresql in a minimal environment, and without llvm
for some reason, then they would ship PGXS in that state without noticing.

The AC_PROG_CXX macro sets CXX to g++ if no C++ compiler is found. Then
a PGXS user would at least get an error message about g++ not found and
they can fix it by installing it. Maybe we should do that under Meson too.

An alternative would be to add some kind of build option or feature to
enable C++ support explicitly.

On Fri, 7 Nov 2025 at 16:39, Peter Eisentraut <peter@eisentraut.org> wrote:

The AC_PROG_CXX macro sets CXX to g++ if no C++ compiler is found. Then
a PGXS user would at least get an error message about g++ not found and
they can fix it by installing it. Maybe we should do that under Meson too.

I think that sounds reasonable.

(although I think using c++ instead of g++ would make more sense
though, but that seems like a separate thread as it would also apply
to that autoconf code)

On Fri Nov 7, 2025 at 9:39 AM CST, Peter Eisentraut wrote:

On 28.09.25 23:16, Tristan Partin wrote:

Attached is a patch which decouples C++ support in PGXS from LLVM for
a Meson-compiled Postgres.

[0]: https://github.com/duckdb/pg_duckdb

With PGConf NYC around the corner, I thought I would rebase the original
patch. Please find v2 attached, which applies on top of
b0fb2c6aa5a485e28210e13ae5536c1231b1261f[0] :D.

This patch makes sense to me. But I wonder what the behavior should be
if no C++ compiler is found. Because then you're back to the state
you're started from, with the confusing make error. If you imagine a
packager building postgresql in a minimal environment, and without llvm
for some reason, then they would ship PGXS in that state without noticing.

The AC_PROG_CXX macro sets CXX to g++ if no C++ compiler is found. Then
a PGXS user would at least get an error message about g++ not found and
they can fix it by installing it. Maybe we should do that under Meson too.

An alternative would be to add some kind of build option or feature to
enable C++ support explicitly.

Great idea. I need to re-spin the patch anyway after a discussion with
Jelte at NYC. I'll be sure to add this as well.

--
Tristan Partin
Databricks (https://databricks.com)

On Fri Nov 7, 2025 at 5:29 PM CET, Tristan Partin wrote:

Great idea. I need to re-spin the patch anyway after a discussion with
Jelte at NYC. I'll be sure to add this as well.

I took the liberty of updating the patch to include the g++ fallback and
simplify the check a little bit (I seem to remember that that was what
we discussed in NYC).

On Fri Jan 2, 2026 at 10:06 AM CST, Jelte Fennema-Nio wrote:

On Fri Nov 7, 2025 at 5:29 PM CET, Tristan Partin wrote:

Great idea. I need to re-spin the patch anyway after a discussion with
Jelte at NYC. I'll be sure to add this as well.

I took the liberty of updating the patch to include the g++ fallback and
simplify the check a little bit (I seem to remember that that was what
we discussed in NYC).

Never saw this email, but here is a little bit cleaner patch. Sorry for
taking a long time to follow up!

--
Tristan Partin
Databricks (https://databricks.com)

On Sat Jan 3, 2026 at 5:49 AM CET, Tristan Partin wrote:

On Fri Jan 2, 2026 at 10:06 AM CST, Jelte Fennema-Nio wrote:

On Fri Nov 7, 2025 at 5:29 PM CET, Tristan Partin wrote:

Great idea. I need to re-spin the patch anyway after a discussion with
Jelte at NYC. I'll be sure to add this as well.

I took the liberty of updating the patch to include the g++ fallback and
simplify the check a little bit (I seem to remember that that was what
we discussed in NYC).

Never saw this email, but here is a little bit cleaner patch. Sorry for
taking a long time to follow up!

I like a lot better how you default to g++. Here's a version of yours
with a few small "improvements" from my last version:
1. Removal of the unnecessary "and not llvmopt.disabled()" check
2. Replacement of a an additional recenlty added llvm.found() check with have_cpp
3. Default to g++ instead of c++. I know I said I liked the c++ better,
and I still do, but it seems better to align with autoconf for now
and then change both of these later if we want to.

On Sat Jan 3, 2026 at 10:42 AM CET, Jelte Fennema-Nio wrote:

3. Default to g++ instead of c++. I know I said I liked the c++ better,
and I still do, but it seems better to align with autoconf for now
and then change both of these later if we want to.

Apparently I had sent an outdated patch... And didn't actually include
that. Fixed now.

On 04.01.26 00:07, Jelte Fennema-Nio wrote:

On Sat Jan 3, 2026 at 10:42 AM CET, Jelte Fennema-Nio wrote:

3. Default to g++ instead of c++. I know I said I liked the c++ better,
   and I still do, but it seems better to align with autoconf for now
   and then change both of these later if we want to.

Apparently I had sent an outdated patch... And didn't actually include
that. Fixed now.

This looks good to me.

There is an unfortunate cpp/cxx naming conflict. For example, this
seems very confusing:

var_cpp = ' '.join(cc.cmd_array() + ['-E'])
...
if have_cpp
var_cxx = ' '.join(cpp.cmd_array())

Here, we use "cpp" to mean two different things in the space of a few lines.

Perhaps we should prefer to use the less ambiguous name "cxx"
throughout. So change

     +have_cpp = add_languages('cpp', required: false, native: false)
     +if have_cpp
     +  cpp = meson.get_compiler('cpp')
     +endif

to

     +have_cxx = add_languages('cpp', required: false, native: false)
     +if have_cxx
     +  cxx = meson.get_compiler('cpp')
     +endif

Then the potentially confusing use of "cpp" is contained in these two lines.

On Mon Jan 5, 2026 at 9:38 AM CET, Peter Eisentraut wrote:

Perhaps we should prefer to use the less ambiguous name "cxx"
throughout.

Done

Hi,

On 2026-01-05 09:56:28 +0100, Jelte Fennema-Nio wrote:

On Mon Jan 5, 2026 at 9:38 AM CET, Peter Eisentraut wrote:

Perhaps we should prefer to use the less ambiguous name "cxx"
throughout.

Done

I've not analyzed why yet, but unfortunately this currently fails in CI:
https://cirrus-ci.com/task/5825100705955840
[18:05:47.624] /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libselinux.so: error adding symbols: file in wrong format

The failure seems somewhat unrelated, odd.

Greetings,

Andres Freund

On Mon Jan 5, 2026 at 10:55 PM CET, Andres Freund wrote:

I've not analyzed why yet, but unfortunately this currently fails in CI:
https://cirrus-ci.com/task/5825100705955840
[18:05:47.624] /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libselinux.so: error adding symbols: file in wrong format

The failure seems somewhat unrelated, odd.

Fixed now (in a separate commit, but feel free to squash them). I had
run into this already on my copyObject patchset, didn't notice that it
also happened here.

On 05.01.26 23:18, Jelte Fennema-Nio wrote:

On Mon Jan 5, 2026 at 10:55 PM CET, Andres Freund wrote:

I've not analyzed why yet, but unfortunately this currently fails in CI:
https://cirrus-ci.com/task/5825100705955840
[18:05:47.624] /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libselinux.so:
error adding symbols: file in wrong format

The failure seems somewhat unrelated, odd.

Fixed now (in a separate commit, but feel free to squash them). I had
run into this already on my copyObject patchset, didn't notice that it
also happened here.

committed