c2hs chokes on OS X availability macros

[mietek]

Symptoms:

$ cabal repl
...
c2hs: C header contains errors:

/usr/include/sys/resource.h:349: (column 75) [ERROR]  >>> Syntax error !
  The symbol `=' does not fit here.

The culprit here is the __OSX_AVAILABLE_STARTING macro, defined in Availability.h, which in turn includes AvailabilityInternal.h.

One workaround is to define the following empty macros prior to including any OS X headers:

#define __AVAILABILITY__
#define __OSX_AVAILABLE_STARTING(a,b)
#define __OSX_AVAILABLE_BUT_DEPRECATED(a,b,c,d)
#define __OSX_AVAILABLE_BUT_DEPRECATED_MSG(a,b,c,d,e)

[ian-ross]

@mietek I've just committed a small patch that may fix this (fb3d035). I've been trying and failing to test it by doing horrible things with Travis (I have no Mac to test it on myself). If you could take a look at it, that would be great. In order to activate the preprocessor definitions to fix this, you need to include a {# nonGNU #} pragma in your CHS file -- this causes the macro definitions you gave to be enabled, which should hopefully make everything work.

[hesselink]

I've run into this problem, and that patch does not seem to fix things for me. Here's part of the output of cabal install -v3 --c2hs-options="-d trace". My file contains {#nonGNU#} and the options seem to be passed to gcc, but the error still occurs. Let me know if you need any more info, or need something tested.

("/Users/erik/.cabal/bin/c2hs",["--cpp=/usr/bin/gcc","--cppopts=-E","--cppopts=-D__GLASGOW_HASKELL__=708","--cppopts=-Ddarwin_BUILD_OS=1","--cppopts=-Dx86_64_BUILD_ARCH=1","--cppopts=-Ddarwin_HOST_OS=1","--cppopts=-Dx86_64_HOST_ARCH=1","--include=dist/dist-sandbox-6f325524/build","--cppopts=-I/Users/erik/Documents/kqueue/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/directory-1.2.1.0/include","--cppopts=-I/Users/erik/Documents/kqueue/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/unix-2.7.0.1/include","--cppopts=-I/Users/erik/Documents/kqueue/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/time-1.5/include","--cppopts=-I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/bytestring-0.10.4.0/include","--cppopts=-I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/base-4.7.0.1/include","--cppopts=-I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/integer-gmp-0.5.1.0/include","--cppopts=-I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/include","--output-dir=dist/dist-sandbox-6f325524/build","--output=System/KQueue.hs","src/System/KQueue.chs","-d","trace"])
Attempting to read file `src/System/KQueue.chs'...
...parsing `src/System/KQueue'...
...successfully loaded `src/System/KQueue'.
Invoking cpp as `/usr/bin/gcc -E -x c -E -D__GLASGOW_HASKELL__=708 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -I/Users/erik/Documents/kqueue/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/directory-1.2.1.0/include -I/Users/erik/Documents/kqueue/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/unix-2.7.0.1/include -I/Users/erik/Documents/kqueue/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/time-1.5/include -I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/bytestring-0.10.4.0/include -I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/base-4.7.0.1/include -I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/integer-gmp-0.5.1.0/include -I/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/include -U__GNUC__ -U__GNUC_MINOR__ -U__GNUC_PATCHLEVEL__ -D__AVAILIBILITY__ -D__OSX_AVAILABLE_STARTING(a,b) -D__OSX_AVAILABLE_BUT_DEPRECATED(a,b,c,d) -D__OSX_AVAILABLE_BUT_DEPRECATED_MSG(a,b,c,d,e) -U__BLOCKS__ -DC2HS_MIN_VERSION(mj,mn,rv)=(mj<=0&&mn<=18&&rv<=2) dist/dist-sandbox-6f325524/build/System/KQueue.chs.h'...
In file included from dist/dist-sandbox-6f325524/build/System/KQueue.chs.h:1:
In file included from /usr/include/sys/time.h:67:
/usr/include/sys/cdefs.h:81:2: warning: "Unsupported compiler detected" [-W#warnings]
#warning "Unsupported compiler detected"
 ^
1 warning generated.
Attempting to read file `dist/dist-sandbox-6f325524/build/System/KQueue.i'...
...parsing `dist/dist-sandbox-6f325524/build/System/KQueue.i'...
...name analysis of `dist/dist-sandbox-6f325524/build/System/KQueue.i'...
...error(s) detected in `dist/dist-sandbox-6f325524/build/System/KQueue.i'.
c2hs: C header contains errors:

/usr/include/sys/time.h:186: (column 96) [ERROR]  >>> Syntax error !
  The symbol `=' does not fit here.

/Users/erik/.cabal/bin/c2hs returned ExitFailure 1

The versions of various things:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3

$ cabal --version
cabal-install version 1.20.0.3
using version 1.20.0.1 of the Cabal library

$ c2hs --version
C->Haskell Compiler, version 0.18.2 The shapeless maps, 31 Oct 2014
  build platform is "x86_64-darwin" <1, True, True, 1>

$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix

[ian-ross]

@hesselink Thanks for the report, Erik. I need to think about what to do with these MacOS problems. I have no access to a Mac myself, so I'm shooting in the dark when it comes to trying to fix these things. I did spend a bit of time trying to set up C2HS MacOS testing on Travis. Maybe I need to give that another try. Otherwise I think we'll just end up with a lot of unproductive "try this", "doesn't work", "try this instead", "still doesn't work" back-and-forth... I'll get back to you in a couple of days when I've tried the Travis route again.

[hesselink]

@ian-ross Yes, I imagine it's tricky debugging things when you have no testing machine. If you still want to try the back-and-forth, we could agree on a time and meet over IRC or some other chat mechanism, to speed up the process. Just let me know.

[ian-ross]

OK, so I've got an OS X testing bodge going on Travis. This fix doesn't work, because the OS X Availability.h header doesn't check whether these things are already defined before defining them itself, so the dummy definitions here get overridden. The real root problem here is that the C parser in the language-c package doesn't support some of the new syntax used in OS X 10.9. There is actually a fork of language-c that does support these things -- https://github.com/acowley/language-c -- and it would be nice if we could get those changes pulled into the main language-c package. I'll do some emailing...