Обсуждение: Time to backpatch config/ax_pthread.m4 changes?

I noticed that buildfarm member quokka (RHEL 7 / ppc64) has started
failing configure in the 9.4 and 9.5 branches.  This appears to be
because configure is not detecting the need to use "-pthread" to get
thread-related functions.  We didn't change anything in that area
ourselves, so I'm guessing that this is a result of a platform update,
which more than likely is going to start affecting other users before
long, so we'd better fix it.

It looks to me like the reason it's okay in 9.6 and up is
commit e97af6c8b ("Replace our hacked version of ax_pthread.m4 with
latest upstream version") plus a few followup fixes.  I propose to
back-patch those into 9.5 and 9.4.  Heikki had attempted to back-patch
into 9.5 originally, but gave up when the followup fixes seemed to
be getting out of hand --- but there weren't really that many.
Anyway, now that that code has been stable for several years, I see
little reason not to back-patch it.

            regards, tom lane

On 19/11/2018 19:12, Tom Lane wrote:
> I noticed that buildfarm member quokka (RHEL 7 / ppc64) has started
> failing configure in the 9.4 and 9.5 branches.  This appears to be
> because configure is not detecting the need to use "-pthread" to get
> thread-related functions.  We didn't change anything in that area
> ourselves, so I'm guessing that this is a result of a platform update,
> which more than likely is going to start affecting other users before
> long, so we'd better fix it.
> 
> It looks to me like the reason it's okay in 9.6 and up is
> commit e97af6c8b ("Replace our hacked version of ax_pthread.m4 with
> latest upstream version") plus a few followup fixes.  I propose to
> back-patch those into 9.5 and 9.4.  Heikki had attempted to back-patch
> into 9.5 originally, but gave up when the followup fixes seemed to
> be getting out of hand --- but there weren't really that many.
> Anyway, now that that code has been stable for several years, I see
> little reason not to back-patch it.

Makes sense.

It would be nice to pick the latest version from the authoritative 
source (https://www.gnu.org/software/autoconf-archive/ax_pthread.html), 
while we're at it. I picked a draft version back then, before it was 
committed to the main branch. Although, if we do that, then the argument 
that the code's been stable for several years doesn't apply anymore...

- Heikki

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 19/11/2018 19:12, Tom Lane wrote:
>> It looks to me like the reason it's okay in 9.6 and up is
>> commit e97af6c8b ("Replace our hacked version of ax_pthread.m4 with
>> latest upstream version") plus a few followup fixes.  I propose to
>> back-patch those into 9.5 and 9.4.  Heikki had attempted to back-patch
>> into 9.5 originally, but gave up when the followup fixes seemed to
>> be getting out of hand --- but there weren't really that many.
>> Anyway, now that that code has been stable for several years, I see
>> little reason not to back-patch it.

> Makes sense.

> It would be nice to pick the latest version from the authoritative 
> source (https://www.gnu.org/software/autoconf-archive/ax_pthread.html), 
> while we're at it. I picked a draft version back then, before it was 
> committed to the main branch. Although, if we do that, then the argument 
> that the code's been stable for several years doesn't apply anymore...

Hm.  I'll check that, but I'm inclined to just make any change like that
in HEAD, since we aren't aware of live bugs it would fix.

            regards, tom lane