[GHC] #7922: adding direct *.c -> object code (*.o/so/dylib) support to compilation driver

[GHC]

#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