adding direct *.c -> object code (*.o/so/dylib) support to compilation driver
currently when GHC is used as the compilation driver for C code, it will always compile the C code (*.c) to assembly (*.s) and then in a subsequent phase map the assembly to the various object formats.
Thusly: the feature request I have is adding support to ghc (perhaps via indication through a new flag) for running the C compiler as something like gcc source.c -c
rather than gcc source.c -s -c
(these are not necessarily the right flags, but rather a strawman representation of the difference).
on certain operating systems, notable OS X, the system provided Assembler (to which there is no, more up to date, alternative) does not support / understand all of the instructions that gcc or clang will emit. Notably, as a general rule, compiling c code with -march=native flag *should not* break. However, on OS X on recent hardware, -march=native will use AVX SIMD instructions / registers if available, which the mac os x assembler doesn't understand. and thus an end user trying to build some haskell and c-code locally will have a very odd error that will take a bit of effort to understand. this took a bit of ef
Likewise, when doing -fllvm compilation, the *.c-> *.s phase just slows down the compilation process period.
I'm still learning the ghc compilation driver architecture, but it seems like this would be a relatively minimal change, and it'd be valuable along a number of atrributes
This is not
Trac metadata
Trac field | Value |
---|---|
Version | 7.7 |
Type | FeatureRequest |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |