Re: pgsql: Replace our hacked version of ax_pthread.m4 with latest upstream - Mailing list pgsql-committers

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 07/08/2015 11:39 PM, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>>> I'll dig a bit deeper, but I think that could be fixed by moving the
>>> AX_PTHREAD call in the configure script earlier, or by temporarily
>>> clearing LIBS before calling it.

>> Ah.  The former sounds sensible from here.

> Pushed that. Should make shearwater happy, but I'm not very sure what
> the problem on gharial is. -lrt is not used there, but one of the other
> libraries is having a similar effect there.

While my RHEL6 box seems happy now, this change has completely broken
pademelon/gaur (which were not broken prior to the rearrangement),
and I believe it also accounts for frogmouth being unhappy.

The pademelon/gaur failure is because we are now failing to detect
any of the major standard C headers:

$ diff pg_config.h.broken pg_config.h.saved
266c266
< /* #undef HAVE_INTTYPES_H */
---
> #define HAVE_INTTYPES_H 1
351c351
< /* #undef HAVE_MEMORY_H */
---
> #define HAVE_MEMORY_H 1
466c466
< /* #undef HAVE_STDLIB_H */
---
> #define HAVE_STDLIB_H 1
475c475
< /* #undef HAVE_STRINGS_H */
---
> #define HAVE_STRINGS_H 1
478c478
< /* #undef HAVE_STRING_H */
---
> #define HAVE_STRING_H 1
568c568
< /* #undef HAVE_SYS_STAT_H */
---
> #define HAVE_SYS_STAT_H 1
577c577
< /* #undef HAVE_SYS_TYPES_H */
---
> #define HAVE_SYS_TYPES_H 1
614c614
< /* #undef HAVE_UNISTD_H */
---
> #define HAVE_UNISTD_H 1
780c780
< /* #undef STDC_HEADERS */
---
> #define STDC_HEADERS 1

Now, this is odd, because those critters build with
--disable-thread-safety and thus shouldn't be executing AX_PTHREAD
at all.  However, I can reproduce something similar to frogmouth's
symptoms on RHEL6 by configuring HEAD with --disable-thread-safety:
configure fails with "zlib version is too old".  And investigation
makes it look like something is completely broken in the major
system headers, not zlib proper, which is what frogmouth is showing.

I suspect the explanation is that physically moving the AX_PTHREAD call
before our regular header checks causes autoconf to move some of the
header checks to be before the AX_PTHREAD expansion, *without regard to
the fact that AX_PTHREAD might not get executed*.

>> This kind of points up that I've always thought the advice at the top of
>> configure.in is a tad broken:
>>
>> dnl 0. Initialization and options processing
>> dnl 1. Programs
>> dnl 2. Libraries
>> dnl 3. Header files
>> dnl 4. Types
>> dnl 5. Structures
>> dnl 6. Compiler characteristics
>> dnl 7. Functions, global variables
>> dnl 8. System services
>>
>> Why isn't "Compiler characteristics" a lot earlier in the list, certainly
>> before "Libraries"?

> Hmm, yeah, although it's not clear what category the pthread check falls
> into.

At this point it's crystal clear that that advice is dead wrong, and that
what we need to be doing is something along the lines of

Initialization and options processing
Compiler characteristics
Header files
Types
Structures
Functions, global variables
Pthreads
Other libraries
Programs
System services

Before we start such major whacking, though, I am curious to know where
Peter got the current ordering advice from.

Also, I'm wondering why we are doing this at all in the 9.5 branch,
because this is sure looking like development not stabilization.

            regards, tom lane