Fix for configure error in 9.5/9.6 on macOS 11.0 Big Sur

From: Thomas Gilligan <thomas(dot)gilligan(at)icloud(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Fix for configure error in 9.5/9.6 on macOS 11.0 Big Sur
Date: 2020-08-02 15:04:52
Message-ID: 09A4B554-82B1-4536-B191-2461342EE0BB@icloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

Under the next version of macOS (11.0 unreleased beta 3), configuring Postgres 9.5 and 9.6 fails with

> checking test program... ok
> checking whether long int is 64 bits... no
> checking whether long long int is 64 bits... no
> configure: error: Cannot find a working 64-bit integer type.

This has been fixed for Postgres 10 and onwards by the following commit. It would be nice for this to be back-ported for people building 9.5 or 9.6 on MacOS.

> commit 1c0cf52b39ca3a9a79661129cff918dc000a55eb
> Author: Peter Eisentraut <peter_e(at)gmx(dot)net>
> Date: Tue Aug 30 12:00:00 2016 -0400
>
> Use return instead of exit() in configure
>
> Using exit() requires stdlib.h, which is not included. Use return
> instead. Also add return type for main().
>
> Reviewed-by: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
> Reviewed-by: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
>
> diff --git a/config/c-compiler.m4 b/config/c-compiler.m4
> index a7f6773ae1..7d901e1f1a 100644
> --- a/config/c-compiler.m4
> +++ b/config/c-compiler.m4
> @@ -71,8 +71,10 @@ int does_int64_work()
> return 0;
> return 1;
> }
> +
> +int
> main() {
> - exit(! does_int64_work());
> + return (! does_int64_work());
> }])],
> [Ac_cachevar=yes],
> [Ac_cachevar=no],
> diff --git a/config/c-library.m4 b/config/c-library.m4
> index d330b0cf95..0a7452c176 100644
> --- a/config/c-library.m4
> +++ b/config/c-library.m4
> @@ -204,8 +204,10 @@ int does_int64_snprintf_work()
> return 0; /* either multiply or snprintf is busted */
> return 1;
> }
> +
> +int
> main() {
> - exit(! does_int64_snprintf_work());
> + return (! does_int64_snprintf_work());
> }]])],
> [pgac_cv_snprintf_long_long_int_modifier=$pgac_modifier; break],
> [],
> diff --git a/configure b/configure
> index 55c771a11e..3eb0faf77d 100755
> --- a/configure
> +++ b/configure
> @@ -13594,8 +13594,10 @@ int does_int64_work()
> return 0;
> return 1;
> }
> +
> +int
> main() {
> - exit(! does_int64_work());
> + return (! does_int64_work());
> }
> _ACEOF
> if ac_fn_c_try_run "$LINENO"; then :
> @@ -13676,8 +13678,10 @@ int does_int64_work()
> return 0;
> return 1;
> }
> +
> +int
> main() {
> - exit(! does_int64_work());
> + return (! does_int64_work());
> }
> _ACEOF
> if ac_fn_c_try_run "$LINENO"; then :
> @@ -13770,8 +13774,10 @@ int does_int64_snprintf_work()
> return 0; /* either multiply or snprintf is busted */
> return 1;
> }
> +
> +int
> main() {
> - exit(! does_int64_snprintf_work());
> + return (! does_int64_snprintf_work());
> }
> _ACEOF
> if ac_fn_c_try_run "$LINENO"; then :

Kindly,
Thomas Gilligan
thomas(dot)gilligan(at)icloud(dot)com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2020-08-02 15:10:23 Re: psql - improve test coverage from 41% to 88%
Previous Message Pavel Stehule 2020-08-02 10:50:12 Re: [HACKERS] [PATCH] Generic type subscripting