Обсуждение: Decouple C++ support in Meson's PGXS from LLVM enablement

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

--
Tristan Partin
Neon (https://neon.tech)

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] :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).

> 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
>
> --
> Tristan Partin
> Neon (https://neon.tech)

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)