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 de
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
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 wit
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-speci
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 comp
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
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 ot
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'
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
> equivalen
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 apple
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
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 necessar
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
15 matches
Mail list logo
