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
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 |