Re: Cannot find a working 64-bit integer type on Illumos - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cannot find a working 64-bit integer type on Illumos
Date
Msg-id 2445195.1733369378@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cannot find a working 64-bit integer type on Illumos  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Cannot find a working 64-bit integer type on Illumos
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Dec 5, 2024 at 1:59 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> I was trying to figure out how I missed this, and I think it might be
>> that the meson build scripts didn't port AC_SYS_LARGEFILES.  So if you
>> build on a 32 bit Linux system with meson (like one of CI's tasks, and
>> also build farm animal adder) then I think you finish up with 32 bit
>> off_t and no SIZEOF_OFF_T, because we don't do AC_SYS_LARGEFILES'
>> dance to figure out if this system needs -D_FILE_OFFSET_BITS=64 (or
>> other similar macros for AIX, Solaris etc).  I will look into that.

> Ahh, correction, it does define it (or else perl would have
> complained), but it seems that meson magically puts it into the
> compiler command line without being asked.  So it is defined without
> pg_config.h being involved, and thus earlier.  Huh.

That does not seem great.  Compile an extension without the same
CPPFLAGS, you silently get an ABI-incompatible module.  We really
ought to be putting these ABI-critical flags into pg_config.h.
It's especially bad that this works differently between autoconf
and meson builds.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: Amit Kapila
Date:
Subject: Re: Disallow UPDATE/DELETE on table with unpublished generated column as REPLICA IDENTITY