Re: meson PGXS compatibility
Hi, On 2022-12-01 12:17:51 -0800, Andres Freund wrote: > I'll push 0001, 0002 shortly. I don't think 0002 is the most elegant approach, > but it's not awful. I'd still like some review for 0003, but will try to push > it in a few days if that's not forthcoming. Pushed 0003 (move export_dynamic determination to configure.ac) and 0004 (PGXS compatibility). Hope there's no fallout from 0003. Greetings, Andres Freund
Re: meson PGXS compatibility
Hi, On 2022-12-01 08:43:19 +0100, Peter Eisentraut wrote: > On 13.10.22 07:23, Andres Freund wrote: > > > > 0005: meson: Add PGXS compatibility > > > > > > > > The actual meson PGXS compatibility. Plenty more replacements to > > > > do, but > > > > suffices to build common extensions on a few platforms. > > > > > > > > What level of completeness do we want to require here? > > > > > > I have tried this with a few extensions. Seems to work alright. I don't > > > think we need to overthink this. The way it's set up, if someone needs > > > additional variables set, they can easily be added. > > > > Yea, I am happy enough with it now that the bulk is out of src/meson.build > > and > > strip isn't set to an outright wrong value. > > How are you planning to proceed with this? I thought it was ready, but it > hasn't moved in a while. I basically was hoping for a review of the prerequisite patches I posted at [1], particularly 0003 (different approach than before, comparatively large). Here's an updated version of the patches. There was a stupid copy-paste bug in the prior version of the 0003 / export_dynamic patch. I'll push 0001, 0002 shortly. I don't think 0002 is the most elegant approach, but it's not awful. I'd still like some review for 0003, but will try to push it in a few days if that's not forthcoming. Greetings, Andres Freund [1] https://www.postgresql.org/message-id/20221013051648.ufz7ud2b5tioctyt%40awork3.anarazel.de >From 53b4063ff6230963ee60122d47b154f91990d097 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Wed, 5 Oct 2022 12:24:14 -0700 Subject: [PATCH v4 1/4] autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C Until now we emitted the cflags to build the CRC objects into architecture specific variables. That doesn't make a whole lot of sense to me - we're never going to target x86 and arm at the same time, so they don't need to be separate variables. It might be better to instead continue to have CFLAGS_SSE42 / CFLAGS_ARMV8_CRC32C be computed by PGAC_ARMV8_CRC32C_INTRINSICS / PGAC_SSE42_CRC32_INTRINSICS and then set CFLAGS_CRC based on those. But it seems unlikely that we'd need other sets of CRC specific flags for those two architectures at the same time. This simplifies the upcoming meson PGXS compatibility. Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6cl...@awork3.anarazel.de --- configure.ac | 10 +- config/c-compiler.m4 | 8 src/port/Makefile | 16 configure | 19 +-- src/Makefile.global.in | 3 +-- 5 files changed, 27 insertions(+), 29 deletions(-) diff --git a/configure.ac b/configure.ac index f76b7ee31fc..6e7c8e09411 100644 --- a/configure.ac +++ b/configure.ac @@ -2091,12 +2091,11 @@ fi # # First check if the _mm_crc32_u8 and _mm_crc32_u64 intrinsics can be used # with the default compiler flags. If not, check if adding the -msse4.2 -# flag helps. CFLAGS_SSE42 is set to -msse4.2 if that's required. +# flag helps. CFLAGS_CRC is set to -msse4.2 if that's required. PGAC_SSE42_CRC32_INTRINSICS([]) if test x"$pgac_sse42_crc32_intrinsics" != x"yes"; then PGAC_SSE42_CRC32_INTRINSICS([-msse4.2]) fi -AC_SUBST(CFLAGS_SSE42) # Are we targeting a processor that supports SSE 4.2? gcc, clang and icc all # define __SSE4_2__ in that case. @@ -2110,12 +2109,13 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [ # # First check if __crc32c* intrinsics can be used with the default compiler # flags. If not, check if adding -march=armv8-a+crc flag helps. -# CFLAGS_ARMV8_CRC32C is set if the extra flag is required. +# CFLAGS_CRC is set if the extra flag is required. PGAC_ARMV8_CRC32C_INTRINSICS([]) if test x"$pgac_armv8_crc32c_intrinsics" != x"yes"; then PGAC_ARMV8_CRC32C_INTRINSICS([-march=armv8-a+crc]) fi -AC_SUBST(CFLAGS_ARMV8_CRC32C) + +AC_SUBST(CFLAGS_CRC) # Select CRC-32C implementation. # @@ -2144,7 +2144,7 @@ if test x"$USE_SLICING_BY_8_CRC32C" = x"" && test x"$USE_SSE42_CRC32C" = x"" && USE_SSE42_CRC32C_WITH_RUNTIME_CHECK=1 else # Use ARM CRC Extension if available. - if test x"$pgac_armv8_crc32c_intrinsics" = x"yes" && test x"$CFLAGS_ARMV8_CRC32C" = x""; then + if test x"$pgac_armv8_crc32c_intrinsics" = x"yes" && test x"$CFLAGS_CRC" = x""; then USE_ARMV8_CRC32C=1 else # ARM CRC Extension, with runtime check? diff --git a/config/c-compiler.m4 b/config/c-compiler.m4 index 000b075312e..eb8cc8ce170 100644 --- a/config/c-compiler.m4 +++ b/config/c-compiler.m4 @@ -597,7 +597,7 @@ fi])# PGAC_HAVE_GCC__ATOMIC_INT64_CAS # the ot
Re: meson PGXS compatibility
On 13.10.22 07:23, Andres Freund wrote: 0005: meson: Add PGXS compatibility The actual meson PGXS compatibility. Plenty more replacements to do, but suffices to build common extensions on a few platforms. What level of completeness do we want to require here? I have tried this with a few extensions. Seems to work alright. I don't think we need to overthink this. The way it's set up, if someone needs additional variables set, they can easily be added. Yea, I am happy enough with it now that the bulk is out of src/meson.build and strip isn't set to an outright wrong value. How are you planning to proceed with this? I thought it was ready, but it hasn't moved in a while.
Re: meson PGXS compatibility
Hi, On 2022-10-12 07:50:07 +0200, Peter Eisentraut wrote: > On 05.10.22 22:07, Andres Freund wrote: > > 0001: autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C > > I wonder, there has been some work lately to use SIMD and such in other > places. Would that affect what kinds of extra CPU-specific compiler flags > and combinations we might need? The current infrastructure is very CRC specific, so I don't think this change would stand in the way of using sse specific flags in other places. > > 0005: meson: Add PGXS compatibility > > > >The actual meson PGXS compatibility. Plenty more replacements to do, but > >suffices to build common extensions on a few platforms. > > > >What level of completeness do we want to require here? > > I have tried this with a few extensions. Seems to work alright. I don't > think we need to overthink this. The way it's set up, if someone needs > additional variables set, they can easily be added. Yea, I am happy enough with it now that the bulk is out of src/meson.build and strip isn't set to an outright wrong value. Thanks! Andres
Re: meson PGXS compatibility
Hi, On 2022-10-10 14:35:14 -0700, Andres Freund wrote: > On 2022-10-05 13:07:10 -0700, Andres Freund wrote: > > 0004: solaris: Check for -Wl,-E directly instead of checking for gnu LD > > > > This allows us to get rid of the nontrivial detection of with_gnu_ld, > > simplifying meson PGXS compatibility. It's also nice to delete libtool.m4. > > > > I don't like the SOLARIS_EXPORT_DYNAMIC variable I invented. If somebody > > has > > a better idea... > > A cleaner approach could be to add a LDFLAGS_BE and emit the -Wl,-E into it > from both configure and meson, solely based on whether -Wl,-E is supported. I > haven't verified cygwin, but on our other platforms that seems to do the right > thing. I think that does look better. See the attached 0003. The attached v3 of this patch has an unchanged 0001 (CRC cflags). For 0002, I still removed LD from Makefile.global, but instead just hardcoded ld in the export file generation portion of the backend build - there's no working alternative linkers, and we already hardcode a bunch of other paths in mkldexport. 0003 is changed significantly - as proposed in the message quoted above, I introduced LDFLAGS_EX_BE and moved the detection -Wl,-E (I used -Wl,--export-dynamic, which we previously only used on FreeBSD) into configure, getting rid of export_dynamic. 0004, the patch introducing PGXS compat, saw a few changes too: - I implemented one of the FIXMEs, the correct determination of strip flags - I moved the bulk of the pgxs compat code to src/makefiles/meson.build - imo src/meson.build got bulked up too much with pgxs-emulation code - some minor cleanups Greetings, Andres Freund >From 6feb84e2f87320f936764aa3d906a8828e080390 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Wed, 5 Oct 2022 12:24:14 -0700 Subject: [PATCH v3 1/4] autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C Until now we emitted the cflags to build the CRC objects into architecture specific variables. That doesn't make a whole lot of sense to me - we're never going to target x86 and arm at the same time, so they don't need to be separate variables. It might be better to instead continue to have CFLAGS_SSE42 / CFLAGS_ARMV8_CRC32C be computed by PGAC_ARMV8_CRC32C_INTRINSICS / PGAC_SSE42_CRC32_INTRINSICS and then set CFLAGS_CRC based on those. But it seems unlikely that we'd need other sets of CRC specific flags for those two architectures at the same time. Discussion: https://postgr.es/m/20221005200710.luvw5evhwf6cl...@awork3.anarazel.de --- src/port/Makefile | 16 config/c-compiler.m4 | 8 configure | 19 +-- configure.ac | 10 +- src/Makefile.global.in | 3 +-- 5 files changed, 27 insertions(+), 29 deletions(-) diff --git a/src/port/Makefile b/src/port/Makefile index b3754d8940a..711f59e32bd 100644 --- a/src/port/Makefile +++ b/src/port/Makefile @@ -88,15 +88,15 @@ libpgport.a: $(OBJS) thread.o: CFLAGS+=$(PTHREAD_CFLAGS) thread_shlib.o: CFLAGS+=$(PTHREAD_CFLAGS) -# all versions of pg_crc32c_sse42.o need CFLAGS_SSE42 -pg_crc32c_sse42.o: CFLAGS+=$(CFLAGS_SSE42) -pg_crc32c_sse42_shlib.o: CFLAGS+=$(CFLAGS_SSE42) -pg_crc32c_sse42_srv.o: CFLAGS+=$(CFLAGS_SSE42) +# all versions of pg_crc32c_sse42.o need CFLAGS_CRC +pg_crc32c_sse42.o: CFLAGS+=$(CFLAGS_CRC) +pg_crc32c_sse42_shlib.o: CFLAGS+=$(CFLAGS_CRC) +pg_crc32c_sse42_srv.o: CFLAGS+=$(CFLAGS_CRC) -# all versions of pg_crc32c_armv8.o need CFLAGS_ARMV8_CRC32C -pg_crc32c_armv8.o: CFLAGS+=$(CFLAGS_ARMV8_CRC32C) -pg_crc32c_armv8_shlib.o: CFLAGS+=$(CFLAGS_ARMV8_CRC32C) -pg_crc32c_armv8_srv.o: CFLAGS+=$(CFLAGS_ARMV8_CRC32C) +# all versions of pg_crc32c_armv8.o need CFLAGS_CRC +pg_crc32c_armv8.o: CFLAGS+=$(CFLAGS_CRC) +pg_crc32c_armv8_shlib.o: CFLAGS+=$(CFLAGS_CRC) +pg_crc32c_armv8_srv.o: CFLAGS+=$(CFLAGS_CRC) # # Shared library versions of object files diff --git a/config/c-compiler.m4 b/config/c-compiler.m4 index 000b075312e..eb8cc8ce170 100644 --- a/config/c-compiler.m4 +++ b/config/c-compiler.m4 @@ -597,7 +597,7 @@ fi])# PGAC_HAVE_GCC__ATOMIC_INT64_CAS # the other ones are, on x86-64 platforms) # # An optional compiler flag can be passed as argument (e.g. -msse4.2). If the -# intrinsics are supported, sets pgac_sse42_crc32_intrinsics, and CFLAGS_SSE42. +# intrinsics are supported, sets pgac_sse42_crc32_intrinsics, and CFLAGS_CRC. AC_DEFUN([PGAC_SSE42_CRC32_INTRINSICS], [define([Ac_cachevar], [AS_TR_SH([pgac_cv_sse42_crc32_intrinsics_$1])])dnl AC_CACHE_CHECK([for _mm_crc32_u8 and _mm_crc32_u32 with CFLAGS=$1], [Ac_cachevar], @@ -613,7 +613,7 @@ AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [Ac_cachevar=no]) CFLAGS="$pgac_save_CFLAGS"]) if test x"$Ac_cachevar" = x"yes"; then - CFLAGS_SSE42="$1" + CFLAGS_CRC="$1" pgac_sse42_crc32_intrinsics=yes fi undefine([Ac_cachevar])dnl @@ -629,7 +62
Re: meson PGXS compatibility
On Wed, Oct 12, 2022 at 12:50 PM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > > On 05.10.22 22:07, Andres Freund wrote: > > 0001: autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C > > I wonder, there has been some work lately to use SIMD and such in other > places. Would that affect what kinds of extra CPU-specific compiler > flags and combinations we might need? In short, no. The functionality added during this cycle only uses instructions available by default on the platform. CRC on Arm depends on armv8-a+crc, and CRC on x86-64 depends on SSE4.2. We can't assume those currently. -- John Naylor EDB: http://www.enterprisedb.com
Re: meson PGXS compatibility
On 05.10.22 22:07, Andres Freund wrote: 0001: autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C I wonder, there has been some work lately to use SIMD and such in other places. Would that affect what kinds of extra CPU-specific compiler flags and combinations we might need? Seems fine otherwise. 0005: meson: Add PGXS compatibility The actual meson PGXS compatibility. Plenty more replacements to do, but suffices to build common extensions on a few platforms. What level of completeness do we want to require here? I have tried this with a few extensions. Seems to work alright. I don't think we need to overthink this. The way it's set up, if someone needs additional variables set, they can easily be added.
Re: meson PGXS compatibility
Hi, On 2022-10-05 13:07:10 -0700, Andres Freund wrote: > 0004: solaris: Check for -Wl,-E directly instead of checking for gnu LD > > This allows us to get rid of the nontrivial detection of with_gnu_ld, > simplifying meson PGXS compatibility. It's also nice to delete libtool.m4. > > I don't like the SOLARIS_EXPORT_DYNAMIC variable I invented. If somebody has > a better idea... A cleaner approach could be to add a LDFLAGS_BE and emit the -Wl,-E into it from both configure and meson, solely based on whether -Wl,-E is supported. I haven't verified cygwin, but on our other platforms that seems to do the right thing. Greetings, Andres Freund
Re: meson PGXS compatibility
Hi, On 2022-10-05 13:07:10 -0700, Andres Freund wrote: > 0003: aix: Build SUBSYS.o using $(CC) -r instead of $(LD) -r > > This is the only direct use of $(LD), and xlc -r and gcc -r end up with the > same set of symbols and similar performance (noise is high, so hard to say > if > equivalent). > > Now that $(LD) isn't needed anymore, remove it from src/Makefile.global > > While at it, add a comment why -r is used. Unfortunately experimenting further with this it turns out I was wrong: While xlc -r results in the same set of symbols, that's not true with gcc -r, at least with some versions of gcc. gcc ends up exposing some of the libgcc symbols. That can be rectified by adding -nostartfiles -nodefaultlibs, but that basically makes the change as-is pointless. I think it'd still be good to get rid of setting LD via configure.ac, mirroring the detection logic in meson sounds like a bad plan. Given this is aix specific, and only the aix linker works on aix (binutils' doesn't), I think the best plan might be to just hardcode ld in the rule generating postgres.imp. Greetings, Andres Freund
Re: meson PGXS compatibility
Hi, On 2022-10-06 11:34:26 +0200, Peter Eisentraut wrote: > On 05.10.22 22:07, Andres Freund wrote: > > My colleague Bilal has set up testing and verified that a few extensions > > build > > with the pgxs compatibility layer, on linux at last. Currently pg_qualstats, > > pg_cron, hypopg, orafce, postgis, pg_partman work. He also tested pgbouncer, > > but for him that failed both with autoconf and meson generated pgxs. > > pgbouncer doesn't use pgxs. Ah, right. It'd still be interesting to make sure it works, but looks like the only integration point is pg_config --includedir and pg_config --libdir, so it should... Greetings, Andres Freund
Re: meson PGXS compatibility
On 05.10.22 22:07, Andres Freund wrote: My colleague Bilal has set up testing and verified that a few extensions build with the pgxs compatibility layer, on linux at last. Currently pg_qualstats, pg_cron, hypopg, orafce, postgis, pg_partman work. He also tested pgbouncer, but for him that failed both with autoconf and meson generated pgxs. pgbouncer doesn't use pgxs.
Re: meson PGXS compatibility
Hi, On 2022-10-05 16:58:46 -0400, Tom Lane wrote: > Andres Freund writes: > > My understanding, from that commit message, was that the issue originates in > > apple's ranlib setting the timestamp to its components but only queries / > > sets > > it using second granularity. I verified that apple's ranlib and ar these > > days > > just set the current time, at a high granularity, as the mtime. Whether or > > not make then hides the problem seems not that relevant if the source of the > > problem is gone, no? > > Well, (a) it seemed to happen in only some circumstances even back then, > so maybe your testing didn't catch it; and (b) even assuming that Apple > has fixed it in recent releases, there may still be people using older, > un-fixed versions. Why's it such a problem to keep the "touch" step? It isn't! That's why I said that I was on the fence about removing the touch in my first email and then that I'd leave the touch there and just s/ranlib/ar/ in my reply to you. Greetings, Andres Freund
Re: meson PGXS compatibility
Andres Freund writes: > My understanding, from that commit message, was that the issue originates in > apple's ranlib setting the timestamp to its components but only queries / sets > it using second granularity. I verified that apple's ranlib and ar these days > just set the current time, at a high granularity, as the mtime. Whether or > not make then hides the problem seems not that relevant if the source of the > problem is gone, no? Well, (a) it seemed to happen in only some circumstances even back then, so maybe your testing didn't catch it; and (b) even assuming that Apple has fixed it in recent releases, there may still be people using older, un-fixed versions. Why's it such a problem to keep the "touch" step? regards, tom lane
Re: meson PGXS compatibility
Hi,
On 2022-10-05 16:20:22 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On macOS we ran ranlib after installing a static library. This was added a
> > long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent
> > macOS versions.
>
> I agree that shouldn't be necessary anymore (and if it is, we'll find
> out soon enough).
Cool.
> > I'm on the fence about removing the "touch $@" from the rule building
> > static
> > libs. That was added because of macos's ranlib not setting fine-grained
> > timestamps. On a modern mac ar and ranlib are the same binary, and maybe
> > that means that ar has the same issue? Both do set fine-grained
> > timestamps:
>
> Please see the commit message for 826eff57c4c: the issue seems to arise
> only with specific combinations of software, in particular with non-Apple
> versions of "make" (although maybe later Apple builds have fixed make's
> failure to read sub-second timestamps?).
My understanding, from that commit message, was that the issue originates in
apple's ranlib setting the timestamp to its components but only queries / sets
it using second granularity. I verified that apple's ranlib and ar these days
just set the current time, at a high granularity, as the mtime. Whether or
not make then hides the problem seems not that relevant if the source of the
problem is gone, no?
> That's a relatively recent hack, and I'm very hesitant to conclude that we
> don't need it anymore just because you failed to reproduce an issue locally.
Yea, that's why I was hesitant as well. I'll reformulate the comment to
reference ar instead of ranlib instead.
> It very possibly isn't a problem in a meson build, though, depending on how
> much meson depends on file timestamps.
Most of the timestamp sensitive stuff is dealt with by ninja, rather than
meson. ninja does take timestamps into account when determining what to
rebuild - although I suspect this specific problem wouldn't occur even with a
problematic ar/ranlib version, because the relevant timestamps will be on the
.c (etc) files, rather than the .a. Ninja has the whole dependency graph, so
it knows what dependencies it has to rebuild, without needing to check
timestamps of intermediary objects.
Ninja does support build rules where it checks the timestamps of build outputs
to see if targets depending on those build outputs have to be rebuilt, or not,
because the target didn't change. But the relevant option ("restat") isn't set
for compiler / linker invocations in the build.ninja meson generates.
Restat is however set for the "custom_command"s we use to generate all kinds
of sources. Sometimes that leads to the set of build steps shrinking
rapidly. E.g. a touch src/include/catalog/pg_namespace.dat starts leads to
ninja considering 1135 targets out of date, but as genbki.pl doesn't end up
changing any files, it's done immediately after that...
[1/1135 1 0%] Generating src/include/catalog/generated_catalog_headers with a
custom command
Greetings,
Andres Freund
Re: meson PGXS compatibility
Andres Freund writes: > On macOS we ran ranlib after installing a static library. This was added a > long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent > macOS versions. I agree that shouldn't be necessary anymore (and if it is, we'll find out soon enough). > I'm on the fence about removing the "touch $@" from the rule building static > libs. That was added because of macos's ranlib not setting fine-grained > timestamps. On a modern mac ar and ranlib are the same binary, and maybe > that means that ar has the same issue? Both do set fine-grained > timestamps: Please see the commit message for 826eff57c4c: the issue seems to arise only with specific combinations of software, in particular with non-Apple versions of "make" (although maybe later Apple builds have fixed make's failure to read sub-second timestamps?). That's a relatively recent hack, and I'm very hesitant to conclude that we don't need it anymore just because you failed to reproduce an issue locally. It very possibly isn't a problem in a meson build, though, depending on how much meson depends on file timestamps. regards, tom lane
meson PGXS compatibility
Hi,
As the meson support stands right now, one cannot easily build an extension
against a postgres built with meson. As discussed at the 2022 unconference
[1], one way to make that easier for extensions is for meson to generate a
complete enough Makefile.global for pgxs.mk to work.
This is a series of patches towards that goal. The first four simplify some
aspects of Makefile.global, and then the fifth generates Makefile.global etc.
0001: autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C
Right now emit the cflags to build the CRC objects into architecture specific
variables. That doesn't make a whole lot of sense to me - we're never going to
target x86 and arm at the same time, so they don't need to be separate
variables.
It might be better to instead continue to have CFLAGS_SSE42 /
CFLAGS_ARMV8_CRC32C be computed by PGAC_ARMV8_CRC32C_INTRINSICS /
PGAC_SSE42_CRC32_INTRINSICS and then set CFLAGS_CRC based on those. But it
seems unlikely that we'd need other sets of flags for those two architectures
at the same time.
The separate flags could be supported by the meson build instead, it'd just
add unneccessary complexity.
0002: autoconf: Rely on ar supporting index creation
With meson we don't require ranlib. But as it is set in Makefile.global and
used by several platforms, we'd need to detect it.
FreeBSD, NetBSD, OpenBSD, the only platforms were we didn't use AROPT=crs,
all have supported the 's' option for a long time.
On macOS we ran ranlib after installing a static library. This was added a
long time ago, in 58ad65ec2def. I cannot reproduce an issue in more recent
macOS versions.
I'm on the fence about removing the "touch $@" from the rule building static
libs. That was added because of macos's ranlib not setting fine-grained
timestamps. On a modern mac ar and ranlib are the same binary, and maybe
that means that ar has the same issue? Both do set fine-grained
timestamps:
cc ../test.c -o test.o -c
rm -f test.a; ar csr test.a test.o ; ranlib test.a; python3 -c "import
os;print(os.stat('test.a').st_mtime_ns)"
1664999109090448534
But I don't know how far back that goes. We could just reformulate the
comment to mention ar instead of ranlib.
Tom, CCing you due to 58ad65ec2def and 826eff57c4c.
0003: aix: Build SUBSYS.o using $(CC) -r instead of $(LD) -r
This is the only direct use of $(LD), and xlc -r and gcc -r end up with the
same set of symbols and similar performance (noise is high, so hard to say if
equivalent).
Now that $(LD) isn't needed anymore, remove it from src/Makefile.global
While at it, add a comment why -r is used.
0004: solaris: Check for -Wl,-E directly instead of checking for gnu LD
This allows us to get rid of the nontrivial detection of with_gnu_ld,
simplifying meson PGXS compatibility. It's also nice to delete libtool.m4.
I don't like the SOLARIS_EXPORT_DYNAMIC variable I invented. If somebody has
a better idea...
0005: meson: Add PGXS compatibility
The actual meson PGXS compatibility. Plenty more replacements to do, but
suffices to build common extensions on a few platforms.
What level of completeness do we want to require here?
A few replacements worth thinking about:
- autodepend - I'm inclined to set it to true when using a gcc like
compiler. I think extension authors won't be happy if suddenly their
extensions don't rebuild reliably anymore. An --enable-depend like
setting doesn't make sense for meson, so we don't have anything to source it
from.
- {LDAP,UUID,ICU}_{LIBS,CFLAGS} - might some extension need them?
For some others I think it's ok to not have replacement. Would be good for
somebody to check my thinking though:
- LIBOBJS, PG_CRC32C_OBJS, TAS: Not needed because we don't build
the server / PLs with the generated makefile
- ZIC: only needed to build tzdata as part of server build
- MSGFMT et al: translation doesn't appear to be supported by pgxs, correct?
- XMLLINT et al: docs don't seem to be supported by pgxs
- GENHTML et al: supporting coverage for pgxs-in-meson build doesn't seem
worth it
- WINDRES: I don't think extensions are bothering to generate rc files on
windows
My colleague Bilal has set up testing and verified that a few extensions build
with the pgxs compatibility layer, on linux at last. Currently pg_qualstats,
pg_cron, hypopg, orafce, postgis, pg_partman work. He also tested pgbouncer,
but for him that failed both with autoconf and meson generated pgxs.
I wonder if and where we could have something like this tested continually?
Greetings,
Andres Freund
[1]
https://wiki.postgresql.org/wiki/PgCon_2022_Developer_Unconference#Meson_new_build_system_proposal
>From 6e24c54141c3063db6d4b2e6e4d43d1cfa563deb Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Wed, 5 Oct 2022 12:24:14 -0700
Subject: [PATCH v2 1/5] autoconf: Unify CFLAGS_SSE42 and CFLAGS_ARMV8_CRC32C
Until
