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
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,
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
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
CRC" = x""; then
USE_ARMV8_CRC32C=1
else
# ARM CRC Extension, with runtime check?
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index 99889167e18..a5e2f36d217 100644
--- a/src/Makefile.global.in
+++ b/src/Makefile.global.in
@@ -262,8 +262,7 @@ CF
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
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
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.
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
>
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,
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
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
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
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
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
is: 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 b
16 matches
Mail list logo
