Opened 4 years ago

Closed 3 years ago

#8197 closed bug (fixed)

telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks

Reported by: carter Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: clang Cc:
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #8480 Differential Rev(s):
Wiki Page:


Are we going to make available directions so that people can use 7.6 correctly with xcode 5 and/or mavericks?

eg: will we provide directions to either

  1. use Luke Ianni's clang wrapper hack, and bundle that with a 7.6 release thats 7.6.3 + that extra binary to make a 10.8 friendly "stability" release
  1. tell people to stick to xcode 4.6 and/or install a newer GCC (say, GCC 4.8) and adjust their ghc settings file to point to that other GCC?

We need to provide this information in a clear way, because this WILL be a problem where we'll have a support load from it (whether we want to or not, until GHC 7.8 gets a haskell platform release, this WILL happen. We need to have a mitigation strategy so that we aren't dealing with it constantly)

Change History (9)

comment:1 Changed 4 years ago by carter

luke ianni's wrapper (which we should explore cleaning up) can be found here

import System.Environment
import System.Process
flags = 
	[ "-Wno-invalid-pp-token" 
	, "-Wno-unicode"
	, "-Wno-trigraphs"
-- See if we're in preprocessor mode
check args@("-E":"-undef":"-traditional":_) = replace args
check other = other
-- make sure we use assembler-with-cpp
replace ("-x":"c":xs) = "-x":"assembler-with-cpp":replace xs
replace (x:xs) = x:replace xs
replace [] = []
main = do
	args <- getArgs
	rawSystem clang $ flags ++ (check args)
clang = "/usr/bin/clang" -- system clang
--clang = "/usr/local/bin/clang" -- clang 3.4/HEAD
--clang = "/usr/local/clang-3.0/bin/clang"
--clang = "/Users/lukexi/bin/clang-3.2/bin/clang"
--clang = "/Users/lukexi/bin/clang-3.3/bin/clang"

NOTE: this is for XCODE 5 / OS X Mavericks only.

comment:2 Changed 4 years ago by carter

the point being that it makes a CLANG that has Austin's patches act like GCC for GHC. (because GHC 7.6 doesn't know how to call clang correctly, because the CPP pass needs to be in clang's ASM CPP mode)

comment:3 Changed 4 years ago by carter

This work around does imply that theres going to NEED to be TWO versions of the next HP release for OS X (which Mark has indicated will be using 7.6)

One version for OS X mavericks / XCode 5 installs

and another for pre Mavericks / Xcode 4.6 and older installs

comment:4 Changed 4 years ago by lukexi

There's an updated version of the script here:

I believe thoughtpolice told me that 7.8 passes the correct flag — can that change simply be backported for a 7.6.4 release instead?

comment:5 Changed 4 years ago by carter

@luke, theres currently no plans for a 7.6.4 (unfortunately)

that said, this bug, and the needed work arounds, if we want 7.6 to work sanely on 10.9 or xcode 5 without crazy hacks for EVERY user, might just merit it. i've made sure the haskell platform folks are aware of this issue,

one work around alternatively is by prepping a 7.6.3 that has your clang wrapper in the bin?

comment:6 Changed 4 years ago by darinmorrison

I agree that something needs to be done. This is going to be a nightmare for a lot of people once 10.9 hits, where Xcode 5 is required.

I haven't tried Luke's script yet but it might be the right way to go.

If we use it, we should ensure it's only called with clang is invoked via GHC, just to be on the safe side and to avoid causing any unforeseen problems for other clang users.

Another alternative is to use apple-gcc42 until 7.8 ships. This is currently what I'm doing on 7.6.3 on 10.9/Xcode 5 and how it works if you install GHC 7.6.3 through homebrew. (apple-gcc42 installs a separate gcc-4.2 binary; it doesn't overwrite any existing gcc/clang stuff).

Unfortunately both the wrapper and the apple-gcc42 approach are hacks. I would honestly be much more in favor of releasing a 7.6.4 that does a proper fix by backporting the clang compatibility patches.

comment:7 Changed 4 years ago by carter

Austin has pointed out that we can find most of the CPP clang patches as follows

[20:01:10] <thoughtpolice>	 you can probably find most of my patches with something like
[20:01:18] <thoughtpolice>	 git log --since="June 2013" --until="July 2013"
[20:01:26] <thoughtpolice>	 which IIRC was about the timeframe I committed most of them
[20:01:36] <thoughtpolice>	 and just grep for my name

comment:8 Changed 3 years ago by hvr

Keywords: clang added

comment:9 Changed 3 years ago by carter

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.