Generating configure from configure.ac

Tatsuo Ishii <ishii@postgresql.org> writes:

I ran autoconf 2.69 on my Ubuntu 20.04 laptop and got the same diffs
plus diffs related runstatedir:

+ --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]

If my understanding is correct, configure in the git repository has
been generated by autoconf 2.69 too. Maybe autoconf 2.69 generates
slightly different results depending on platform?

If you use a vendor-supplied package of autoconf, you are likely
to get such diffs because of vendor patches. The expectation in
our usage is that committers will use exactly the GNU release
of autoconf, which is available from

https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz

IME it's pretty painless to build it from source, so this isn't
a big deal. I recommend installing it into its own directory
(so it doesn't get messed up by system-software updates) and
adding that directory to your PATH.

regards, tom lane

Tatsuo Ishii <ishii@postgresql.org> writes:

I ran autoconf 2.69 on my Ubuntu 20.04 laptop and got the same diffs
plus diffs related runstatedir:

+ --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]

If my understanding is correct, configure in the git repository has
been generated by autoconf 2.69 too. Maybe autoconf 2.69 generates
slightly different results depending on platform?

If you use a vendor-supplied package of autoconf, you are likely
to get such diffs because of vendor patches. The expectation in
our usage is that committers will use exactly the GNU release
of autoconf, which is available from

https://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz

Thanks for the quick response. Ok, the point is always use autoconf
from the original source code, not use the autoconf coming with the
platform.

BTW, in my understanding, patch posters do not need to submit a patch
for configure, a patch for configure.ac is enough since configure will
be generated by committers anyway (if the patch gets committed).

Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

Tatsuo Ishii <ishii@postgresql.org> writes:

BTW, in my understanding, patch posters do not need to submit a patch
for configure, a patch for configure.ac is enough since configure will
be generated by committers anyway (if the patch gets committed).

Right. Even if the submitter includes a diff for configure,
it's best to redo it at the point of commit, just to make sure
it was done with a vanilla version of autoconf.

regards, tom lane

On Tue, Nov 26, 2024 at 2:29 PM Tatsuo Ishii <ishii@postgresql.org> wrote:

-#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
+#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31))

. o O ( I wonder if that missing Debian/Ubuntu bugfix[1]https://sources.debian.org/patches/autoconf2.69/2.69-3.1/ is why our
AIX animals have -D_LARGE_FILES=1 jammed into $CC, even though
AC_SYS_LARGEFILES claims to understand AIX )

[1]: https://sources.debian.org/patches/autoconf2.69/2.69-3.1/

Thomas Munro <thomas.munro@gmail.com> writes:

. o O ( I wonder if that missing Debian/Ubuntu bugfix[1] is why our
AIX animals have -D_LARGE_FILES=1 jammed into $CC, even though
AC_SYS_LARGEFILES claims to understand AIX )

I'm dubious. The two likely results if off_t is 32 bits are
(1) the compiler shifts the 1 off into never-never land, producing
zero, or (2) the compiler throws an error about shift distance too
large. Either one will lead to the test failing as-desired.
Yeah, the C spec theoretically licenses the compiler to halt
and catch fire, but that's not going to happen in practice.
(Thus Sven Joachim's doubt in the linked bug discussion that
anything is actually broken.)

It seems plausible to me that the -D_LARGE_FILES=1 settings in our
AIX animals' configuration are carried over from some dim past where
we didn't have this configure test, or it was implemented even less
correctly than now. I wonder whether Noah has any records of their
origin.

regards, tom lane

On Tue, Nov 26, 2024 at 12:07:59AM -0500, Tom Lane wrote:

It seems plausible to me that the -D_LARGE_FILES=1 settings in our
AIX animals' configuration are carried over from some dim past where
we didn't have this configure test, or it was implemented even less
correctly than now. I wonder whether Noah has any records of their
origin.

It's tied to Python defining _LARGE_FILES when PostgreSQL doesn't. More info:
/messages/by-id/20180531224129.GB3343825@rfd.leadboat.com

I have some other notes on the topic, but that thread has the major points.