invalid argument '-std=c++11' not allowed with 'C/ObjC'

[hjwylde]

Tried to upgrade to from 3.4.5.4 to 3.5.0.0 but I'm getting this invalid argument error when building llvm-general. System is OS X Yosimite. If you need any specific information let me know - or if it's on my end also let me know :P.

Configuring llvm-general-3.5.0.0...
Building llvm-general-3.5.0.0...
Preprocessing library llvm-general-3.5.0.0...
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
compiling .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/LLVM/General/Internal/LibraryFunction_hsc_make.c failed (exit code 1)
command was: /usr/bin/gcc -c .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/LLVM/General/Internal/LibraryFunction_hsc_make.c -o .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/LLVM/General/Internal/LibraryFunction_hsc_make.o -m64 -fno-stack-protector -D__GLASGOW_HASKELL__=710 -Ddarwin_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Ddarwin_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Isrc -I/usr/local/Cellar/llvm35/3.5.1/lib/llvm-3.5/include -std=c++11 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -I.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/autogen -include .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/autogen/cabal_macros.h -I/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/time_AXTdBF9VRQoBOqJT6qtmVH/include -I/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw/include -I/usr/local/Cellar/ghc/7.10.2/libexec/integer-gmp/include -I/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/include -I/usr/local/Cellar/ghc/7.10.2/lib/ghc-7.10.2/include/

[bscarlet]

With my toolchains, I get a similar message but it's only a warning. I'm not surprised that the OS X gcc would behave differently, but I am surprised it would do so only for the new llvm-general release. Was your 3.4.5.4 possibly built with an older version of Xcode? Could you please try rebuilding the older version with exactly the same toolchain?

[Gal3riel]

Same situation here.

error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
compiling dist/dist-sandbox-62a9abd5/build/LLVM/General/Internal/LibraryFunction_hsc_make.c failed (exit code 1)

The version of clang is

clang -v                                                                            
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

[Gal3riel]

I tried to downgrade llvm to 3.4.* and recompile llvm-general-3.4.6.0 this time, It works perfectly.

[hjwylde]

Apologies I haven't given this a go yet, I will test out rebuilding LLVM 3.4 on the same toolchain tomorrow.

[hjwylde]

With the same toolchain: built LLVM 3.4 successfully, 3.5 fails with the same error.

gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

Tried again after installing gcc from Homebrew and I can compile 3.5 successfully. (I did have to symlink gcc to gcc-5 temporarily.)

gcc --version
gcc (Homebrew gcc 5.2.0) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[hjwylde]

Travis CI seems to also be failing with a similar error after trying to update the YAML to use LLVM 3.5: https://travis-ci.org/qux-lang/qux/jobs/88588577

cc1: error: unrecognized command line option ‘-std=c++11’

.travis.yaml: https://github.com/qux-lang/qux/blob/0a43f8e744a3a2e3aff362234c10d4f6fda8fe8e/.travis.yml

I tried running the CI with gcc = 5 and g++ = 5 too but same error: https://travis-ci.org/qux-lang/qux/jobs/88588234

[bscarlet]

That's odd. My travis build has been working fine.

[bscarlet]

I can reproduce it if I use a different travis config, more like yours, though.

[bscarlet]

hjwylde: your travis problem is a little different. Your .travis.yml files add gcc & g++ packages, but don't change which gcc is on the path. You're invoking the travis default, which is 4.6 and does not support c++11. That's different from the OS X problem, where for some reason your compiler is more picky about letting me specify c++11 support when compiling c. I need c++11 support for my .cc files, but I think it's failing when it passes that flag when compiling a c file produced from hsc. More to follow.

[hjwylde]

Doh. Sorry, my oversight. That makes the Travis issue interesting then. I can't override the version of GCC without sudo. Cabal doesn't seem to acknowledge ghc-options for specifying which c compiler to use (e.g. change to gcc-4.8). I'm guessing that means until they fix that I won't be able to use dockerised builds on Travis if I want to use LLVM 3.5.

Ahh yup. Will be interested to see how it goes :).

[dalaing]

I removed

cc-options: -std=c++11

from the cabal file, and it got a lot further, until

src/LLVM/General/Internal/FFI/AssemblyC.cpp

and blew up with

fatal error: 'cmath' file not found

It seems like we need no options for compiling .c files (like it does in Setup.hs) and the included options for compiling the .cpp files.

Just found this, which seems relevant.

[bscarlet]

Correct. The core problem is that Cabal provides very poor control over the flags used for compiling individual files. I want to compile my .cpp files one way, and the .c files generated by hsc2hs another. I'm working on code for Setup.hs, but the Cabal code is strange beast, riddled with hard coded assumptions and extension hooks that interact in messy ways.

[dalaing]

I'm going to make an attempt at fixing that Cabal issue and see how far I get.

On Fri, 13 Nov 2015, 8:36 PM Benjamin S. Scarlet notifications@github.com wrote:

Correct. The core problem is that Cabal provides very poor control over the flags used for compiling individual files. I want to compile my .cpp files one way, and the .c files generated by hsc2hs another. I'm working on code for Setup.hs, but the Cabal code is strange beast, riddled with hard coded assumptions and extension hooks that interact in messy ways.

— Reply to this email directly or view it on GitHub https://github.com/bscarlet/llvm-general/issues/155#issuecomment-156392866 .

[bscarlet]

1ee693c on llvm-3.5 includes a hack to address this issue. Please try building with the head of the llvm-3.5 branch to verify that it fixes the problem for you.

[tmcdonell]

https://github.com/bscarlet/llvm-general/commit/1ee693cc7577aab2f3e11ec9bd7f4244a5182c89 is working for me. I've only tested with llvm-3.5 and ghc-7.10.2 so far.

[fserb]

Same error here. 1ee693c worked for me too.

[ashutoshrishi]

The commit 1ee693cc7577aab2f3e11ec9bd7f4244a5182c89 does not appear with the package llvm-general-3.5.1.0 from Hackage.

[tmcgilchrist]

Any chance that the llvm-3.5 branch will get released? It's working for me too.

[bscarlet]

Yes. It should be released in the next day or two. I am listening.

[tmcgilchrist]

Thanks much appreciated.

On Wednesday, 3 February 2016, Benjamin S. Scarlet notifications@github.com wrote:

Yes. It should be released in the next day or two. I am listening.

— Reply to this email directly or view it on GitHub https://github.com/bscarlet/llvm-general/issues/155#issuecomment-178828692 .

[bscarlet]

I'm somewhat hindered verifying a new release by an issue at travis-ci. https://www.traviscistatus.com/incidents/lpgbdfcmjhpk

[bscarlet]

Released in 3.5.1.1