Thread: Generating configure from configure.ac
While looking into this: https://www.postgresql.org/message-id/20241119193121.7ba727c489b5f0b6d20f9c25%40sraoss.co.jp I noticed that the patch for configure includes diffs against the current configure script in the git repository in addition to his changes to configure.ac. @@ -14728,7 +14729,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#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)) 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? So my question is, are there any specific requirements for using autoconf to generate configure from configure.ac besides the autoconf version? 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: > 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] 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: https://www.postgresql.org/message-id/flat/20180531224129.GB3343825%40rfd.leadboat.com I have some other notes on the topic, but that thread has the major points.