Thread: [BUGS] ./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
Дилян Палаузов <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 befixed one day, and today is a good opportunity for this particular piece. Regards Дилян On 10/10/17 17:01, Tom Lane wrote: > Дилян Палаузов <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
Дилян Палаузов 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
--- src/include/pg_config.h.save 2017-10-10 11:15:40.160422393 -0400
+++ src/include/pg_config.h 2017-10-10 12:10:55.461411757 -0400
@@ -76,7 +76,7 @@
#define FLOAT8PASSBYVAL true
/* Define to 1 if gettimeofday() takes only 1 argument. */
-/* #undef GETTIMEOFDAY_1ARG */
+#define GETTIMEOFDAY_1ARG 1
#ifdef GETTIMEOFDAY_1ARG
# define gettimeofday(a,b) gettimeofday(a)
@@ -101,7 +101,7 @@
/* #undef HAVE_BIO_METH_NEW */
/* Define to 1 if you have the `cbrt' function. */
-#define HAVE_CBRT 1
+/* #undef HAVE_CBRT */
/* Define to 1 if you have the `class' function. */
/* #undef HAVE_CLASS */
@@ -359,7 +359,7 @@
/* #undef HAVE_MBSTOWCS_L */
/* Define to 1 if you have the `memmove' function. */
-#define HAVE_MEMMOVE 1
+/* #undef HAVE_MEMMOVE */
/* Define to 1 if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1
@@ -413,7 +413,7 @@
/* #undef HAVE_PTHREAD_IS_THREADED_NP */
/* Have PTHREAD_PRIO_INHERIT. */
-#define HAVE_PTHREAD_PRIO_INHERIT 1
+/* #undef HAVE_PTHREAD_PRIO_INHERIT */
/* Define to 1 if you have the `random' function. */
#define HAVE_RANDOM 1
@@ -434,7 +434,7 @@
#define HAVE_READLINK 1
/* Define to 1 if you have the `rint' function. */
-#define HAVE_RINT 1
+/* #undef HAVE_RINT */
/* Define to 1 if you have the global variable
'rl_completion_append_character'. */
@@ -462,7 +462,7 @@
#define HAVE_SHM_OPEN 1
/* Define to 1 if you have the `snprintf' function. */
-#define HAVE_SNPRINTF 1
+/* #undef HAVE_SNPRINTF */
/* Define to 1 if you have spinlocks. */
#define HAVE_SPINLOCKS 1
@@ -604,7 +604,7 @@
#define HAVE_TYPEOF 1
/* Define to 1 if you have the external array `tzname'. */
-#define HAVE_TZNAME 1
+/* #undef HAVE_TZNAME */
/* Define to 1 if you have the <ucred.h> header file. */
/* #undef HAVE_UCRED_H */
@@ -658,7 +658,7 @@
/* #undef HAVE_UUID_UUID_H */
/* Define to 1 if you have the `vsnprintf' function. */
-#define HAVE_VSNPRINTF 1
+/* #undef HAVE_VSNPRINTF */
/* Define to 1 if you have the <wchar.h> header file. */
#define HAVE_WCHAR_H 1
@@ -676,16 +676,16 @@
/* #undef HAVE__BUILTIN_BSWAP16 */
/* Define to 1 if your compiler understands __builtin_bswap32. */
-#define HAVE__BUILTIN_BSWAP32 1
+/* #undef HAVE__BUILTIN_BSWAP32 */
/* Define to 1 if your compiler understands __builtin_bswap64. */
-#define HAVE__BUILTIN_BSWAP64 1
+/* #undef HAVE__BUILTIN_BSWAP64 */
/* Define to 1 if your compiler understands __builtin_constant_p. */
-#define HAVE__BUILTIN_CONSTANT_P 1
+/* #undef HAVE__BUILTIN_CONSTANT_P */
/* Define to 1 if your compiler understands __builtin_types_compatible_p. */
-#define HAVE__BUILTIN_TYPES_COMPATIBLE_P 1
+/* #undef HAVE__BUILTIN_TYPES_COMPATIBLE_P */
/* Define to 1 if your compiler understands __builtin_unreachable. */
#define HAVE__BUILTIN_UNREACHABLE 1
@@ -845,7 +845,7 @@
/* #undef USE_PAM */
/* Use replacement snprintf() functions. */
-/* #undef USE_REPL_SNPRINTF */
+#define USE_REPL_SNPRINTF 1
/* Define to 1 to use Intel SSE 4.2 CRC instructions with a runtime check. */
/* #undef USE_SLICING_BY_8_CRC32C */
@@ -913,7 +913,7 @@
/* Define to `__inline__' or `__inline' if that's what the C compiler
calls it, or to nothing if 'inline' is not supported under any name. */
#ifndef __cplusplus
-/* #undef inline */
+#define inline
#endif
/* Define to the type of a signed integer type wide enough to hold a pointer,
@@ -921,7 +921,7 @@
/* #undef intptr_t */
/* Define to empty if the C compiler does not understand signed types. */
-/* #undef signed */
+#define signed /**/
/* Define to how the compiler spells `typeof'. */
/* #undef typeof */
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 2017-10-10 11:01:15 -0400, Tom Lane wrote: > Дилян Палаузов <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