./configure error: Cannot find a working 64-bit integer type
Hello,
unless the patch below is applied ./configure prints:
STDOUT checking test program... ok
STDOUT checking whether long int is 64 bits... no
STDOUT checking whether long long int is 64 bits... no
STDERR configure: error: Cannot find a working 64-bit integer type.
when gcc 8.0.0 20171006 is used, "unset CFLAGS" is removed from configure(.in), having in config.site:
CFLAGS="-pipe -Werror -Wall -Wextra -O3 -fno-fat-lto-objects -flto"
LDFLAGS="-Wl,-O1,-s -flto=12"
and calling
PYTHON=/usr/local/bin/python3 ./configure --prefix=/usr/local --with-gssapi --with-openssl --with-libxml --with-libxslt --with-python --enable-cassert
config.log contains then:
configure:14132: checking whether long long int is 64 bits
configure:14192: gcc -o conftest -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-label
conftest.c:154:5: error: no previous prototype for 'does_int64_work' [-Werror=missing-prototypes]
int does_int64_work(void)
^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
configure:14192: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
[...]
| */
| ac_int64 a = 20000001;
| ac_int64 b = 40000005;
| int does_int64_work()
| {
| ac_int64 c,d;
|
diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
index 6dcc790..dfaa273 100644
--- a/config/c-compiler.m4
+++ b/config/c-compiler.m4
@@ -56,8 +56,8 @@ AC_CACHE_CHECK([whether $1 is 64 bits], [Ac_cachevar],
*/
ac_int64 a = 20000001;
ac_int64 b = 40000005;
-
-int does_int64_work()
+int does_int64_work(void);
+int does_int64_work(void)
{
ac_int64 c,d;Regards
Дилян
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
=?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <dpa-postgres@aegee.org> writes:
unless the patch below is applied ./configure prints:
You can't run configure with -Werror; there are too many things it does
that aren't clean according to bleeding-edge compilers. This particular
issue is only the tip of the iceberg, and most of the problems are not
ours but Autoconf's, so we can't fix them.
The preferred method if you want to use -Werror is to include it in
COPT, as mentioned near the bottom of
https://www.postgresql.org/docs/current/static/install-procedure.html
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Hello Tom,
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.
Regards
Дилян
On 10/10/17 17:01, Tom Lane wrote:
=?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <dpa-postgres@aegee.org> writes:
unless the patch below is applied ./configure prints:
You can't run configure with -Werror; there are too many things it does
that aren't clean according to bleeding-edge compilers. This particular
issue is only the tip of the iceberg, and most of the problems are not
ours but Autoconf's, so we can't fix them.The preferred method if you want to use -Werror is to include it in
COPT, as mentioned near the bottom ofhttps://www.postgresql.org/docs/current/static/install-procedure.html
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Дилян Палаузов wrote:
Hello Tom,
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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alvaro Herrera <alvherre@alvh.no-ip.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I wrote:
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.
Just to prove the point, I applied the proposed patch, ran configure
with CFLAGS="-O2 -Werror", and compared the output to what I normally
get.
I first had to remove --with-python, because it said that Python.h
couldn't be compiled. The logfile shows
configure:15997: gcc -c -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -O2 -Werror -I/usr/include/python2.6 -D_GNU_SOURCE conftest.c >&5
In file included from /usr/include/python2.6/pyconfig.h:6,
from /usr/include/python2.6/Python.h:8,
from conftest.c:197:
/usr/include/python2.6/pyconfig-64.h:1034:1: error: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/stdio.h:28,
from conftest.c:164:
/usr/include/features.h:162:1: error: this is the location of the previous definition
In file included from /usr/include/python2.6/pyconfig.h:6,
from /usr/include/python2.6/Python.h:8,
from conftest.c:197:
/usr/include/python2.6/pyconfig-64.h:1043:1: error: "_XOPEN_SOURCE" redefined
In file included from /usr/include/stdio.h:28,
from conftest.c:164:
/usr/include/features.h:164:1: error: this is the location of the previous definition
It's not clear to me why those complaints show up in this mode, because
I don't see them when actually building PG. So the blame might lie with
Autoconf or with Python, but in any case this is likely not something
PG could fix.
Without that option, the configure run went through, but I got all of the
attached diffs in pg_config.h, none of which are good. The build step
failed immediately, apparently because of the incorrect conclusions about
builtin bswap functions.
regards, tom lane
Attachments:
pg_config-diffs-with-Werror.difftext/x-diff; charset=us-ascii; name=pg_config-diffs-with-Werror.diffDownload+15-15
On 2017-10-10 11:01:15 -0400, Tom Lane wrote:
=?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <dpa-postgres@aegee.org> writes:
unless the patch below is applied ./configure prints:
You can't run configure with -Werror; there are too many things it does
that aren't clean according to bleeding-edge compilers. This particular
issue is only the tip of the iceberg, and most of the problems are not
ours but Autoconf's, so we can't fix them.
Right. It's to the point I wonder if we shouldn't error out in configure
and/or filter it out if Werror is specified. If the latter we could
still leave it enabled in the persisted cflags.
The preferred method if you want to use -Werror is to include it in
COPT, as mentioned near the bottom of
I think a ./configure --use-werror or something would make this less
painful.
Greetings,
Andres Freund
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Andres Freund <andres@anarazel.de> writes:
On 2017-10-10 11:01:15 -0400, Tom Lane wrote:
You can't run configure with -Werror; there are too many things it does
that aren't clean according to bleeding-edge compilers. This particular
issue is only the tip of the iceberg, and most of the problems are not
ours but Autoconf's, so we can't fix them.
Right. It's to the point I wonder if we shouldn't error out in configure
and/or filter it out if Werror is specified. If the latter we could
still leave it enabled in the persisted cflags.
Hm, filtering it out and then putting it back at the end would be a
pretty transparent fix. I don't feel like investing work in that,
but if you do ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs