Closed cartazio closed 2 months ago
is that really something that should be done in the .cabal
file? shouldn't GHC know what compiler to run (and the options that it accepts) when it encounters a .m
file?
(that said, i'm ok with a workaround, but doesn't this break things for users with no clang?)
No Mac user with lion and newer will ever lack clang if they have dev tools installed, and it's currently broken for me unless I do pgma clang pgmc clang, because my ghc uses real GCC by default.
Likewise, mixing clang vs GCC actually is slightly broken because cabal / ghc invokes the assembler separate from the c compiler, and that seems to break things if you mix both. I'll test more to sanity check this claim of mine later this afternoon
On Thursday, February 27, 2014, Luite Stegeman notifications@github.com wrote:
is that really something that should be done in the .cabal file? shouldn't GHC know what compiler to run (and the options that it accepts) when it encounters a .m file?
(that said, i'm ok with a workaround, but doesn't this break things for users with no clang?)
— Reply to this email directly or view it on GitHubhttps://github.com/luite/hfsevents/issues/8#issuecomment-36247234 .
I just ran into this problem as well, when compiling the latest stack : stack upgrade --git
. Where should one supply those flags in this case?
I'm on OSX 10.9.5, using stack version 0.1.4.0
I'm not sure if stack lets you specify per package configuration flags. So you may be shit out of luck. Also why isn't your GHC using clang for both cpp and c code and asm? On Dec 3, 2015 5:51 AM, "Marco Zocca" notifications@github.com wrote:
I just ran into this problem as well, when compiling the latest stack : stack upgrade --git . Where should one supply those flags in this case
— Reply to this email directly or view it on GitHub https://github.com/luite/hfsevents/issues/8#issuecomment-161596313.
I'd rather find my answers elsewhere than thinking of being "shit out of luck". Thank you
I've been hesitant to patch this package, since the problem points to a GHC installation issue rather than a problem with the package itself. Instead of hardcoding a compiler program name in all packages that need to compile Objective C it's best to fix the the problem at its source.
GHC gets the underlying compiler commands to use from its settings file (you can find the location with ghc --print-libdir
and dump the config with ghc --info
. How did you install your GHC?
Agreed. Your error indicates a misconfigured Mac install of ghc. Could you provide more information about your config?
On Friday, December 4, 2015, Luite Stegeman notifications@github.com wrote:
I've been hesitant to patch this package, since the problem points to a GHC installation issue rather than a problem with the package itself. Instead of hardcoding a compiler program name in all packages that need to compile Objective C it's best to fix the the problem at its source.
GHC gets the underlying compiler commands to use from its settings file (you can find the location with ghc --print-libdir and dump the config with ghc --info. How did you install your GHC?
— Reply to this email directly or view it on GitHub https://github.com/luite/hfsevents/issues/8#issuecomment-161962752.
I think this has been fixed by GHC and/or cabal by now
(welcome to open a new issue if new workarounds are needed of course)
Building hfsevents-0.1.5... Preprocessing library hfsevents-0.1.5... [1 of 1] Compiling System.OSX.FSEvents ( System/OSX/FSEvents.hs, dist/build/System/OSX/FSEvents.o ) gcc-4.8: error: language objective-c not recognized gcc-4.8: error: language objective-c not recognized
if i pass -pgmc clang -pgma clang things work out fine