#7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver ---------------------------------+------------------------------------------ Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #7904 | ---------------------------------+------------------------------------------ Comment(by carter): {{{gcc -c -S foo.c ; clang -c foo.s }}} works, via gcc doesnt HOWEVER, if i add the following flags to the ghc options section of cabal: {{{ ghc-options: -fllvm -pgma clang -pgmc clang }}} the build still doesn't work! (same error as before) I '''can''' change the ghc settings file to have {{{clang}}} be the default c compiler and then the build succeeds {{{ carter code/test ยป cabal clean ; cabal configure ; cabal build cleaning... Resolving dependencies... Configuring test-0.1.0.0... Warning: The 'license-file' field refers to the file 'LICENSE' which does not exist. /var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/81694.c:1:12: warning: control reaches end of non-void function [-Wreturn-type] int foo() {} ^ 1 warning generated. Building test-0.1.0.0... Preprocessing executable 'test' for test-0.1.0.0... [1 of 1] Compiling Main ( src/main.hs, dist/build/test/test- tmp/Main.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... Linking dist/build/test/test ... }}} This would not work if I had any haskell modules running the clang C preprocessor however. (if that issue isn't in the relevant clang tickets, I can spend some time making a small reproducible test case) but theres a number of issues still outstanding with using clang as the default c compiler, including the fact that with the default flags, clang errors out when used as the c preprocessor . So i'm not comfortable with this ticket being closed until at least thats sorted out. Likewise, as Nathan Howell pointed out, not providing the .c->.o variant 1. adds an extra step to build processes that have lots of c code (and doubly so on the llvm) 2. makes it possible to just provide -pgmc clang for the relevant code and have things work (and doesn't require the end user / library client to have clang as their c compiler in the ghc settings file, which isn't something normal ghc users should have to fiddle with ) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7922#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler