Обсуждение: Error running configure on Mac
./configure
...
checking for gcc option to accept ISO C99... unsupported
configure: error: C compiler "gcc" does not support C99
When I do gcc --version I see:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-1300.0.27.3)
Target: x86_64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
So, it looks like it is using clang to compile and not gcc.
configure runs successfully if I do: ./configure CC=gcc-11 or soft link gcc to gcc-11 and then run configure. However, I didn't find these tips in Platform specific notes in docs: https://www.postgresql.org/docs/9.6/installation-platform-notes.html#INSTALLATION-NOTES-MACOS.
So, I wanted to ask if this behavior is expected and if so, should we update docs to make a note of this?
Regards,
Samay
samay sharma <smilingsamay@gmail.com> writes:
> I was trying to build Postgres from source on my Mac (MacOS Monterey 12.1)
> and ran into an error when running configure.
Works for me, and for other developers, and for assorted buildfarm
animals.
> checking for gcc option to accept ISO C99... unsupported
> configure: error: C compiler "gcc" does not support C99
That is bizarre. Can you show the segment of config.log
that corresponds to this? The exact error message that
the compiler is reporting would be useful.
Also, I wonder if you are using Apple's gcc (yeah, that's
really clang), or a gcc from MacPorts or Brew or the like.
regards, tom lane
samay sharma <smilingsamay@gmail.com> writes:
> I was trying to build Postgres from source on my Mac (MacOS Monterey 12.1)
> and ran into an error when running configure.
Works for me, and for other developers, and for assorted buildfarm
animals.
> checking for gcc option to accept ISO C99... unsupported
> configure: error: C compiler "gcc" does not support C99
That is bizarre. Can you show the segment of config.log
that corresponds to this? The exact error message that
the compiler is reporting would be useful.
configure:4607: result: unsupported
configure:4623: error: C compiler "gcc" does not support C99
Slightly above that, I see this error message too:
configure:4591: gcc -qlanglvl=extc99 -c -g -O2 conftest.c >&5
clang: error: unknown argument: '-qlanglvl=extc99'
configure:4591: $? = 1
configure: failed program was:
....
I also see many more error messages in config.log when I grep for error. So, I've attached the entire file in case any other output is useful.
Also, I wonder if you are using Apple's gcc (yeah, that's
really clang), or a gcc from MacPorts or Brew or the like.
regards, tom lane
Вложения
Hi,
On 2022-01-23 23:44:11 -0800, samay sharma wrote:
> I also see many more error messages in config.log when I grep for error.
> So, I've attached the entire file in case any other output is useful.
The important lines seem to be:
configure:4591: gcc -c -g -O2 conftest.c >&5
In file included from conftest.c:21:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/stdlib.h:66:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/sys/wait.h:110:
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/sys/resource.h:202:2: error: unknown type name
'uint8_t'
uint8_t ri_uuid[16];
I.e. that for some reason on your system stdlib.h is not standalone. Which is
quite bizarre.
Grepping through headers on an m1 mini running monterey, I see
sys/resource.h:
#include <sys/cdefs.h>
...
#if __DARWIN_C_LEVEL >= __DARWIN_C_FULL
#include <stdint.h>
#endif /* __DARWIN_C_LEVEL >= __DARWIN_C_FULL */
sys/cdefs.h:
#if defined(_ANSI_SOURCE)
#define __DARWIN_C_LEVEL __DARWIN_C_ANSI
#elif defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE) && !defined(_NONSTD_SOURCE)
#define __DARWIN_C_LEVEL _POSIX_C_SOURCE
#else
#define __DARWIN_C_LEVEL __DARWIN_C_FULL
#endif
So it seems that the problem is that for some reason your environment ends up
with __DARWIN_C_LEVEL being set to something too low?
It's interesting that all the _POSIX_C_SOURCE values are smaller than
__DARWIN_C_LEVEL, which seems to indicate that the above include of stdint.h
won't be made if _POSIX_C_SOURCE is set?
Could you create a test.c file like:
#include <stdarg.h>
#include <stdbool.h>
#include <stdlib.h>
#include <wchar.h>
#include <stdio.h>
and then run
gcc -v -E -dD test.c -o test.i
and then share both the output of that and test.i?
Greetings,
Andres Freund
Hi,
On 2022-01-23 23:44:11 -0800, samay sharma wrote:
> I also see many more error messages in config.log when I grep for error.
> So, I've attached the entire file in case any other output is useful.
The important lines seem to be:
configure:4591: gcc -c -g -O2 conftest.c >&5
In file included from conftest.c:21:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/stdlib.h:66:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/sys/wait.h:110:
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/sys/resource.h:202:2: error: unknown type name 'uint8_t'
uint8_t ri_uuid[16];
I.e. that for some reason on your system stdlib.h is not standalone. Which is
quite bizarre.
Grepping through headers on an m1 mini running monterey, I see
sys/resource.h:
#include <sys/cdefs.h>
...
#if __DARWIN_C_LEVEL >= __DARWIN_C_FULL
#include <stdint.h>
#endif /* __DARWIN_C_LEVEL >= __DARWIN_C_FULL */
sys/cdefs.h:
#if defined(_ANSI_SOURCE)
#define __DARWIN_C_LEVEL __DARWIN_C_ANSI
#elif defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE) && !defined(_NONSTD_SOURCE)
#define __DARWIN_C_LEVEL _POSIX_C_SOURCE
#else
#define __DARWIN_C_LEVEL __DARWIN_C_FULL
#endif
So it seems that the problem is that for some reason your environment ends up
with __DARWIN_C_LEVEL being set to something too low?
It's interesting that all the _POSIX_C_SOURCE values are smaller than
__DARWIN_C_LEVEL, which seems to indicate that the above include of stdint.h
won't be made if _POSIX_C_SOURCE is set?
Could you create a test.c file like:
#include <stdarg.h>
#include <stdbool.h>
#include <stdlib.h>
#include <wchar.h>
#include <stdio.h>
and then run
gcc -v -E -dD test.c -o test.i
and then share both the output of that and test.i?
Apple clang version 13.0.0 (clang-1300.0.27.3)
Target: x86_64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
"/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple x86_64-apple-macosx12.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -E -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.c -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-strict-return -fno-rounding-math -munwind-tables -target-sdk-version=12.1 -fvisibility-inlines-hidden-static-local-var -target-cpu penryn -tune-cpu generic -debugger-tuning=lldb -target-linker-version 710.1 -v -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/13.0.0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk -I/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/lib/clang/13.0.0/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.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 -Wno-elaborated-enum-base -fdebug-compilation-dir /Users/sash/PostgreSQL_Dev -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -fcommon -fcolor-diagnostics -dD -clang-vendor-feature=+nullptrToBoolConversion -clang-vendor-feature=+messageToSelfInClassMethodIdReturnType -clang-vendor-feature=+disableInferNewAvailabilityFromInit -clang-vendor-feature=+disableNeonImmediateRangeCheck -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+revert09abecef7bbf -mllvm -disable-aligned-alloc-awareness=1 -mllvm -enable-dse-memoryssa=0 -o test.i -x c test.c
clang -cc1 version 13.0.0 (clang-1300.0.27.3) default target x86_64-apple-darwin21.2.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/local/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/Library/Developer/CommandLineTools/usr/lib/clang/13.0.0/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks (framework directory)
End of search list.
Greetings,
Andres Freund
Вложения
Hi, On 2022-01-24 08:41:39 -0800, samay sharma wrote: > I've also attached the test.i file. The problem is that you got a stdint.h in /usr/local/include/. And that stdint.h doesn't match the system one. Which explains why there's a compilation failure and also explains why others don't see this problem. from test.i > # 1 "/usr/local/include/stdint.h" 1 3 4 > > #define _ISL_INCLUDE_ISL_STDINT_H 1 > > #define _GENERATED_STDINT_H "isl 0.14.1" > > #define _STDINT_HAVE_STDINT_H 1 > > # 1 "/usr/local/include/stdint.h" 1 3 4 > # 8 "/usr/local/include/stdint.h" 2 3 4 > # 73 "/Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/usr/include/sys/resource.h" 2 3 4 Greetings, Andres Freund