Stack: ISO C99 compiler support missing

[DerekMaffett]

General summary

After moving the contents of my old computer to a new one, I tried to continue working on a project, but stack build commands no longer work. The initial issue was with the user directory having a space in it, which I fixed. Now the problem is that the gcc compiler claims not to support ISO C99. I tried uninstalling by removing the stack directories as recommended and reinstalling, but the same error happens.

I'm trying to re-install xcode on the slim chance that there's a cascading problem from there, but it doesn't seem that there's an actual problem. I've looked up the gcc problem but I can't seem to find reference to this type of error.

Steps to reproduce

I simply run stack build within the directory of my project (working project configs, they're fine on my original computer).

Expected

Successful build.

Actual

$ stack build --verbose

.......................
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.529338: [debug] checking whether ln -s works... yes
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.530375: [debug] checking for gsed... /usr/local/bin/gsed
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.535773: [debug] xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.536813: [debug] checking XCode version... not found (too old?)
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.539858: [debug] checking for gcc... gcc
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.708548: [debug] checking whether the C compiler works... yes
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.708738: [debug] checking for C compiler default output file name... a.out
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.758931: [debug] checking for suffix of executables...
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.837547: [debug] checking whether we are cross compiling... no
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.879930: [debug] checking for suffix of object files... o
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.916359: [debug] checking whether we are using the GNU C compiler... yes
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:19.955271: [debug] checking whether gcc accepts -g... yes
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.020848: [debug] checking for gcc option to accept ISO C89... none needed
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.052109: [debug] checking for llc-3.9... no
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.054000: [debug] checking for llc... no
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.056943: [debug] checking for opt-3.9... no
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.059073: [debug] checking for opt... no
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.096943: [debug] checking version of gcc... 9.1.0
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.124954: [debug] checking whether GCC supports -no-pie... yes
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.202154: [debug] checking how to run the C preprocessor... gcc -E
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.271032: [debug] checking for extra options to pass gcc when compiling via C...  -fwrapv -fno-builtin
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.717825: [debug] checking for gcc option to accept ISO C99... unsupported
@(src/Stack/Setup.hs:1097:54)
2018-07-29 10:45:20.718008: [debug] configure: error: C99-compatible compiler needed
@(src/Stack/Setup.hs:1097:54)
Configuring GHC ...
Received ExitFailure 1 when running
Raw command: /Users/derekmaffett/.stack/programs/x86_64-osx/ghc-8.2.2.temp/ghc-8.2.2/configure --prefix=/Users/derekmaffett/.stack/programs/x86_64-osx/ghc-8.2.2/
Run from: /Users/derekmaffett/.stack/programs/x86_64-osx/ghc-8.2.2.temp/ghc-8.2.2/

Stack version

$ stack --version
Version 1.7.1, Git revision 681c800873816c022739ca7ed14755e85a579565 (5807 commits) x86_64 hpack-0.28.2

$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Method of installation

curl -sSL https://get.haskellstack.org/ | sh

[mihaimaruseac]

I think this is an issue on the C compiler, not on Stack.

[Blaisorblade]

The problem is between some package's install routine (GHC's?) and the installed compiler.

The compiler, while called gcc, is in fact Apple's clang — it just offers a gcc binary since many programs expect that.

I expect this is likely an issue with the compiler installation, since it seems that (a) clang does support C99, and it seems that -std=c99 should enable it (b) clang is the default compiler on Mac (c) GHC supports Macs. There might be some upstream integration bug. A stack bug seems unlikely.

EDIT: took me a while, but-std is described at
https://opensource.apple.com/source/clang/clang-137/src/tools/clang/docs/UsersManual.html#commandline

clang supports the -std option, which changes what language mode clang uses. The supported modes for C are c89, gnu89, c94, c99, gnu99 and various aliases for those modes. If no -std option is specified, clang defaults to gnu99 mode.

Same info at https://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes, which seems the more standard location.

EDIT 2; Apparently those docs are old, https://www.phoronix.com/scan.php?page=news_item&px=MTgyMzM, but that still doesn't explain the issue. gcc -std=c99 works locally, even in the environment created by stack, so something is wrong on your computer:

$ echo 'main() {}' > foo.c
$ stack exec -- gcc  -std=c99 -o main foo.c
foo.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main() {}
^
1 warning generated.

[DerekMaffett]

Okay. I'll see about restarting from scratch or comparing with my old computer once I have access to it again next week. Thanks!

[m-shaka]

Is this problem solved? I encountered same one, but can not solve it. @DerekMaffett

[DerekMaffett]

I haven't been able to solve it unfortunately. The same version of clang exists on my other computer but there everything works. My remaining option is to completely reset the computer at this point...

[Blaisorblade]

Have you tried redownloading 8.2.2?
But on the other computer ghc is already installed, right? And this still happens on the new computer when XCode is installed? OTOH, I don't have XCode installed, and I get the following, on macOS 10.13.6:

2018-08-16 12:31:11.514811: [debug] checking build system type... x86_64-apple-darwin17.7.0
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.515143: [debug] checking host system type... x86_64-apple-darwin17.7.0
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.515478: [debug] checking target system type... x86_64-apple-darwin17.7.0
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.515962: [debug] Build platform inferred as: x86_64-apple-darwin
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.526949: [debug] Host platform inferred as: x86_64-apple-darwin
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.537843: [debug] Target platform inferred as: x86_64-apple-darwin
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.590842: [debug] GHC build  : x86_64-apple-darwin
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.590958: [debug] GHC host   : x86_64-apple-darwin
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.591148: [debug] GHC target : x86_64-apple-darwin
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.596054: [debug] checking for path to top of build tree... /Users/pgiarrusso/.stack/programs/x86_64-osx/ghc-8.2.2.temp/ghc-8.2.2
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.597010: [debug] checking for perl... /usr/local/bin/perl
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.615169: [debug] checking for a BSD-compatible install... /usr/local/bin/ginstall -c
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.624520: [debug] xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.624726: [debug] checking whether ln -s works... yes
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.624872: [debug] checking for gsed... /usr/local/bin/gsed
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.629759: [debug] checking XCode version... not found (too old?)
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.630869: [debug] checking for gcc... gcc
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.808442: [debug] checking whether the C compiler works... yes
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.808546: [debug] checking for C compiler default output file name... a.out
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.865748: [debug] checking for suffix of executables...
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:11.951311: [debug] checking whether we are cross compiling... no
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.004364: [debug] checking for suffix of object files... o
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.052582: [debug] checking whether we are using the GNU C compiler... yes
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.109606: [debug] checking whether gcc accepts -g... yes
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.263722: [debug] checking for gcc option to accept ISO C89... none needed
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.303881: [debug] checking for llc-3.9... no
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.305139: [debug] checking for llc... no
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.306844: [debug] checking for opt-3.9... no
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.308113: [debug] checking for opt... no
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.345846: [debug] checking version of gcc... 9.1.0
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.378675: [debug] checking whether GCC supports -no-pie... yes
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.476879: [debug] checking how to run the C preprocessor... gcc -E
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.853063: [debug] checking for extra options to pass gcc when compiling via C...  -fwrapv -fno-builtin
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:12.971229: [debug] checking for gcc option to accept ISO C99... none needed
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:13.054439: [debug] checking for gcc option to accept ISO C99... none needed
@(src/Stack/Setup.hs:1101:54)
2018-08-16 12:31:13.131856: [debug] checking for gcc option to accept ISO C99... none needed

[Blaisorblade]

For further debugging, I'd recommend unpacking the downloaded tarball in /Users/pgiarrusso/.stack/programs/x86_64-osx/ghc-8.2.2.tar.bz2, running configure in there by hand, and posting (in a gist) the config.log you got after the failure.
EDIT: I'd also check if installing the original tarball (https://www.haskell.org/ghc/download_ghc_8_2_2.html#macosx_x86_64) works, just to know if this is about the Stack tarball or something else.

[m-shaka]

Header files caused the problem. This worked for me!
https://github.com/SOHU-Co/kafka-node/issues/881#issuecomment-396197724

[Blaisorblade]

@m-shaka makes sense, but can you post the offending headers in a gist? Same for others (@DerekMaffett).
I'm curious what program installed them, so we can bug that program to stop breaking machines.

FWIW: that makes sense because configure detects C99 support by trying to compile some C99 program (which I posted here: https://gist.github.com/Blaisorblade/75190a6eb3e5eac9cc3d6d6d8b759f7d).

[DerekMaffett]

Well, halleliu... halleylei... haleleu... hot diggity, that worked! Thanks, @m-shaka!

Here's the offending headers @Blaisorblade :
https://gist.github.com/DerekMaffett/c46897471b4553ff46ee33da8718b0d7

[Blaisorblade]

This is certainly not a Stack bug, so closing; I'd still like to report this upstream but it's unclear whence it might come from.

So I have that file in /usr/local/include/unistring/stdint.h, and there it's fine — it comes from https://www.gnu.org/software/libunistring/. If you have it in say /usr/local/include/stdint.h, you have a problem.

It seems that include might come from a mangled install of libunistring, but sadly I can't divine how this arises, and I don't see a point in filing a bug with libunistring since what they do seems fine.