Re: ./configure error: Cannot find a working 64-bit integer type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Дилян Палаузов <dpa-postgres(at)aegee(dot)org>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: ./configure error: Cannot find a working 64-bit integer type
Date: 2017-10-10 16:02:59
Message-ID: 16007.1507651379@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Дилян Палаузов wrote:
>> if the aim is one day to be able to run with -Werror, as far as the
>> problems are within PG, then this snippet needs to be fixed one day,
>> and today is a good opportunity for this particular piece.

> I don't think we have any expectations that we would ever allow
> configure to run with -Werror.

The problem with configure is that it *expects* to get failures,
and silently copes with them. This means that whenever
$blithering_idiot_compiler_maintainer decides that some legal-per-spec
coding pattern deserves a warning, -Werror will mean that configure
decides that features are missing from your O/S, and then we silently
work around them as best we can. This is not what you want to have
happen.

I might be more excited about making this work if compiler warnings
weren't such a moving target ... but they are. So trying to make
configure work with -Werror would just be an unending source of pain
and/or bad performance.

Given that situation, I think it's actually a good thing that the int64
test is coded the way it is, as it stops anyone from trying to use -Werror
here.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2017-10-10 16:26:28 Re: ./configure error: Cannot find a working 64-bit integer type
Previous Message Alvaro Herrera 2017-10-10 15:24:57 Re: ./configure error: Cannot find a working 64-bit integer type