Thread: Fix for configure error in 9.5/9.6 on macOS 11.0 Big Sur
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
forpeople building 9.5 or 9.6 on MacOS.
> commit 1c0cf52b39ca3a9a79661129cff918dc000a55eb
> Author: Peter Eisentraut <peter_e@gmx.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@iki.fi>
> Reviewed-by: Thomas Munro <thomas.munro@enterprisedb.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.gilligan@icloud.com
Thomas Gilligan <thomas.gilligan@icloud.com> writes:
> 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.
Hm, could we see the config.log output for this? I'm not 100% convinced
that you've diagnosed the problem accurately, because it'd imply that
Apple made some fundamentally incompatible changes in libc, which
seems like stirring up trouble for nothing.
regards, tom lane
On 2020-08-02 23:18, Tom Lane wrote: > Thomas Gilligan <thomas.gilligan@icloud.com> writes: >> 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. > > Hm, could we see the config.log output for this? I'm not 100% convinced > that you've diagnosed the problem accurately, because it'd imply that > Apple made some fundamentally incompatible changes in libc, which > seems like stirring up trouble for nothing. It looks like the new compiler errors out on calling undeclared functions. Might be good to see config.log to confirm this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi Peter,
Yeah it's funny I got this immediately after upgrading to Big Sur (beta
5). I found commit 1c0cf52b39ca3 but couldn't quite find the mailing
list thread on it from 4 years ago (it lists Heikki and Thomas Munro as
reviewers). Was it prompted by a similar error you encountered?
On Tue, Aug 25, 2020 at 6:57 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2020-08-02 23:18, Tom Lane wrote:
> > Thomas Gilligan <thomas.gilligan@icloud.com> writes:
> >> 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.
> >
> > Hm, could we see the config.log output for this? I'm not 100% convinced
> > that you've diagnosed the problem accurately, because it'd imply that
> > Apple made some fundamentally incompatible changes in libc, which
> > seems like stirring up trouble for nothing.
>
> It looks like the new compiler errors out on calling undeclared
> functions. Might be good to see config.log to confirm this.
Yeah here's an excerpt from config.log verbatim (I'm not wrapping the
lines):
| configure:13802: checking whether long int is 64 bits
| configure:13860: ccache clang -o conftest -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing
-fwrapv -Wno-unused-command-line-argument -g -O0 conftest.c -lz
-lreadline -lm >&5
| conftest.c:169:5: warning: no previous prototype for function
'does_int64_work' [-Wmissing-prototypes]
| int does_int64_work()
| ^
| conftest.c:169:1: note: declare 'static' if the function is not
intended to be used outside of this translation unit
| int does_int64_work()
| ^
| static
| conftest.c:183:1: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
| main() {
| ^
| conftest.c:184:3: error: implicitly declaring library function
'exit' with type 'void (int) __attribute__((noreturn))'
[-Werror,-Wimplicit-function-declaration]
| exit(! does_int64_work());
| ^
| conftest.c:184:3: note: include the header <stdlib.h> or explicitly
provide a declaration for 'exit'
| 2 warnings and 1 error generated.
Cheers,
Jesse
On 2020-Sep-02, Jesse Zhang wrote: > Hi Peter, > > Yeah it's funny I got this immediately after upgrading to Big Sur (beta > 5). I found commit 1c0cf52b39ca3 but couldn't quite find the mailing > list thread on it from 4 years ago (it lists Heikki and Thomas Munro as > reviewers). Was it prompted by a similar error you encountered? https://postgr.es/m/bf9de63c-b669-4b8c-d33b-4a5ed11cd5d4@2ndquadrant.com -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Wow thanks Alvaro! My search of "most obvious keywords" didn't turn this up. On Wed, Sep 2, 2020 at 2:18 PM Alvaro Herrera wrote: > > On 2020-Sep-02, Jesse Zhang wrote: > > > Hi Peter, > > > > Yeah it's funny I got this immediately after upgrading to Big Sur (beta > > 5). I found commit 1c0cf52b39ca3 but couldn't quite find the mailing > > list thread on it from 4 years ago (it lists Heikki and Thomas Munro as > > reviewers). Was it prompted by a similar error you encountered? > > https://postgr.es/m/bf9de63c-b669-4b8c-d33b-4a5ed11cd5d4@2ndquadrant.com Cheers, Jesse
On 2020-09-02 22:43, Jesse Zhang wrote: > | conftest.c:184:3: error: implicitly declaring library function > 'exit' with type 'void (int) __attribute__((noreturn))' > [-Werror,-Wimplicit-function-declaration] > | exit(! does_int64_work()); > | ^ > | conftest.c:184:3: note: include the header <stdlib.h> or explicitly > provide a declaration for 'exit' > | 2 warnings and 1 error generated. Where did the -Werror come from? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > On 2020-09-02 22:43, Jesse Zhang wrote: >> | conftest.c:184:3: error: implicitly declaring library function >> 'exit' with type 'void (int) __attribute__((noreturn))' >> [-Werror,-Wimplicit-function-declaration] > Where did the -Werror come from? Peter wasn't entirely explicit here, but note the advice at the end of https://www.postgresql.org/docs/devel/install-procedure.html that you cannot include -Werror in any CFLAGS you tell configure to use. It'd be nice if autoconf was more robust about that, but it is not our bug to fix. regards, tom lane
Hi Tom and Peter, On Wed, Sep 2, 2020 at 10:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > > On 2020-09-02 22:43, Jesse Zhang wrote: > >> | conftest.c:184:3: error: implicitly declaring library function > >> 'exit' with type 'void (int) __attribute__((noreturn))' > >> [-Werror,-Wimplicit-function-declaration] > > > Where did the -Werror come from? > > Peter wasn't entirely explicit here, but note the advice at the end of > > https://www.postgresql.org/docs/devel/install-procedure.html > > that you cannot include -Werror in any CFLAGS you tell configure > to use. It'd be nice if autoconf was more robust about that, > but it is not our bug to fix. > > regards, tom lane If you noticed the full invocation of clang, you'd notice that Werror is nowhere on the command line, even though the error message suggests otherwise. I think this is a behavior from the new AppleClang, here's the minimal repro: int main() { exit(0); } And boom! $ clang -c c.c c.c:1:14: error: implicitly declaring library function 'exit' with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration] int main() { exit(0); } ^ c.c:1:14: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit' 1 error generated. My environment: $ uname -rsv Darwin 20.0.0 Darwin Kernel Version 20.0.0: Fri Aug 14 00:25:13 PDT 2020; root:xnu-7195.40.44.151.1~4/RELEASE_X86_64 $ clang --version Apple clang version 12.0.0 (clang-1200.0.31.1) Target: x86_64-apple-darwin20.0.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin I've heard reports of the same under the latest Xcode 12 on macOS Catalina, but I don't have my hands on such an env. Cheers, Jesse
Jesse Zhang <sbjesse@gmail.com> writes:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> Where did the -Werror come from?
> If you noticed the full invocation of clang, you'd notice that Werror is
> nowhere on the command line, even though the error message suggests
> otherwise. I think this is a behavior from the new AppleClang,
Hmph. If you explicitly say -Wno-error, does the error drop back down
to being a warning?
> I've heard reports of the same under the latest Xcode 12 on macOS
> Catalina, but I don't have my hands on such an env.
The latest thing available to the unwashed masses seems to be
Xcode 11.7 with
$ clang --version
Apple clang version 11.0.3 (clang-1103.0.32.62)
At least, that's what I got when I reinstalled Xcode just now on
my Catalina machine. It does not exhibit this behavior. I see
$ clang -c c.c
c.c:1:14: warning: implicitly declaring library function 'exit' with type 'void
(int) __attribute__((noreturn))' [-Wimplicit-function-declaration]
int main() { exit(0); }
^
c.c:1:14: note: include the header <stdlib.h> or explicitly provide a
declaration for 'exit'
1 warning generated.
and PG configure and build goes through just fine.
Smells like an Apple bug from here. Surely they're not expecting
that anyone will appreciate -Werror suddenly being the default.
regards, tom lane
On 2020-09-03 19:36, Tom Lane wrote:
> At least, that's what I got when I reinstalled Xcode just now on
> my Catalina machine. It does not exhibit this behavior. I see
>
> $ clang -c c.c
> c.c:1:14: warning: implicitly declaring library function 'exit' with type 'void
> (int) __attribute__((noreturn))' [-Wimplicit-function-declaration]
> int main() { exit(0); }
> ^
> c.c:1:14: note: include the header <stdlib.h> or explicitly provide a
> declaration for 'exit'
> 1 warning generated.
>
> and PG configure and build goes through just fine.
>
> Smells like an Apple bug from here. Surely they're not expecting
> that anyone will appreciate -Werror suddenly being the default.
IIRC, calling an undeclared function is (or may be?) an error in C99.
So perhaps the implicit -Werror only applies to this particular warning
class.
I suppose backpatching the patch that fixed this would be appropriate.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I suppose backpatching the patch that fixed this would be appropriate.
[ confused ... ] Back-patching what patch?
regards, tom lane
On 2020-09-04 07:52, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> I suppose backpatching the patch that fixed this would be appropriate. > > [ confused ... ] Back-patching what patch? Commit 1c0cf52b39ca3a9a79661129cff918dc000a55eb was mentioned at the beginning of the thread. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Sep 3, 2020 at 10:36 AM Tom Lane wrote: > > Jesse Zhang writes: > >> Peter Eisentraut writes: > >>> Where did the -Werror come from? > > > If you noticed the full invocation of clang, you'd notice that Werror is > > nowhere on the command line, even though the error message suggests > > otherwise. I think this is a behavior from the new AppleClang, > > Hmph. If you explicitly say -Wno-error, does the error drop back down > to being a warning? Yeah something like that, this is what works for me: clang -Wno-error=implicit-function-declaration c.c Then it became a warning. Interestingly, it seems that AppleClang incorrectly forces this warning on us: $ clang --verbose c.c | Apple clang version 12.0.0 (clang-1200.0.31.1) | Target: x86_64-apple-darwin20.0.0 | Thread model: posix | InstalledDir: /Library/Developer/CommandLineTools/usr/bin | "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple x86_64-apple-macosx11.0.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name c.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mframe-pointer=all -fno-strict-return -masm-verbose -munwind-tables -target-sdk-version=11.0 -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 609 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/12.0.0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/lib/clang/12.0.0/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Library/Developer/CommandLineTools/usr/include -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 193 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fobjc-runtime=macosx-11.0.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/ts/nxrsmhmd0xb5zdrlqb4jlkbr0000gn/T/c-e6802f.o -x c c.c | clang -cc1 version 12.0.0 (clang-1200.0.31.1) default target x86_64-apple-darwin20.0.0 Notice that -Werror=implicit-function-declaration up there? I spent a few minutes digging in Apple's published fork of LLVM, they've been forcing this error flag for quite a while, but this particular warning-turned-error is guarded by a conditional along the lines of "is this iOS-like" [1][2], so I cannot imagine such a code path is activated (other than something like "goto fail;" from 2014) > > > I've heard reports of the same under the latest Xcode 12 on macOS > > Catalina, but I don't have my hands on such an env. > > The latest thing available to the unwashed masses seems to be > Xcode 11.7 with Yes you're right. Xcode 12 is still beta. > > Smells like an Apple bug from here. Surely they're not expecting > that anyone will appreciate -Werror suddenly being the default. I think you've convinced me that this is an Apple bug indeed. I'll probably just get by with a Wno-error=implicit-function-declaration in my CFLAGS for now. [1] https://github.com/apple/llvm-project/blob/swift-5.3-DEVELOPMENT-SNAPSHOT-2020-08-04-a/clang/lib/Driver/ToolChains/Darwin.cpp#L952-L962 [2] https://opensource.apple.com/source/clang/clang-800.0.42.1/src/tools/clang/lib/Driver/ToolChains.cpp
Jesse Zhang <sbjesse@gmail.com> writes:
> Notice that -Werror=implicit-function-declaration up there? I spent a
> few minutes digging in Apple's published fork of LLVM, they've been
> forcing this error flag for quite a while, but this particular
> warning-turned-error is guarded by a conditional along the lines of "is
> this iOS-like" [1][2],
Wow, [1] is interesting:
// For iOS and watchOS, also error about implicit function declarations,
// as that can impact calling conventions.
if (!isTargetMacOSBased())
CC1Args.push_back("-Werror=implicit-function-declaration");
I wonder if the new Xcode version dropped the not-macOS restriction
on doing this? It's not much of a stretch of the imagination
to guess that the iOS/watchOS issue is related to Apple's ABI
conventions for ARM, in which case they might have to do the
same for macOS to get it to run on ARM ... which we can expect
that Big Sur is ready for.
Anyway, I'm now satisfied that we understand where the problem really
lies, so +1 for back-patching 1c0cf52b39ca3.
regards, tom lane
On 2020-09-05 17:27, Tom Lane wrote:
> Jesse Zhang <sbjesse@gmail.com> writes:
>> Notice that -Werror=implicit-function-declaration up there? I spent a
>> few minutes digging in Apple's published fork of LLVM, they've been
>> forcing this error flag for quite a while, but this particular
>> warning-turned-error is guarded by a conditional along the lines of "is
>> this iOS-like" [1][2],
>
> Wow, [1] is interesting:
>
> // For iOS and watchOS, also error about implicit function declarations,
> // as that can impact calling conventions.
> if (!isTargetMacOSBased())
> CC1Args.push_back("-Werror=implicit-function-declaration");
>
> I wonder if the new Xcode version dropped the not-macOS restriction
> on doing this? It's not much of a stretch of the imagination
> to guess that the iOS/watchOS issue is related to Apple's ABI
> conventions for ARM, in which case they might have to do the
> same for macOS to get it to run on ARM ... which we can expect
> that Big Sur is ready for.
>
> Anyway, I'm now satisfied that we understand where the problem really
> lies, so +1 for back-patching 1c0cf52b39ca3.
done
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services