GHC and the location of the Mac developer tools
mark.lentczner at gmail.com
Sun May 20 19:35:33 CEST 2012
There have been problems with installs on Mac OS X recently due to the
changes that Apple has been making in Xcode. I did some deep investigation
and thought I'd share my notes, and my plan for handling it in HP
Turns out Xcode has been moved the location of the developer command line
tools (gcc, ar, etc...) several times in the Xcode 4 line of releases,
depending on the release (4.1, 4.2, or 4.3), on how they were installed,
and what options the user choose, they can be in any of these places:
For example, under Xcode 4.3, the command line tools are installed in the
last location listed above. However, if the user chooses the "command line
tools" download option in Xcode's preferences, then they get a copy (!) in
/usr/bin. Prior to Xcode 4.3, users had the option to install Xcode other
than at /Developer, leading to the third option listed above.
In all GHC's the location of individual tools can be overridden on the
command line. Prior installers used this to set the user's actual location
of the tools in the shell scripts that actually start the GHC executable.
This is unsatisfying because there are many such tools to set, when in
reality, most of them are just aliases for gcc -- and one has to be sure
all ways of invoking GHC get all those options.
In 7.4.1 GHC uses a settings file to tell it the location of gcc from which
it derives all the other defaults. This is nice as at installation time, we
can determine the locations of the tools and set it here. I've written a
tool to do this and it will be included in the HP release, and the HP
installer will call it in the post-installation step. The user can re-run
it if they upgrade Xcode and things get broken.
This tool and/or code could optionally be called in the scripts that launch
GHC. A small issue is that settings is installed root, and so the tool
needs sudo to run (or be suid root - ick!) Another option is to just do
this search in GHC itself when on Mac. I'd be happy to prepare that patch,
if that seems like a good idea.
A wholly different approach could be used: GHC could just presume that the
tools are on the user's PATH. I'm not sure what the downside of this
approach would be. GHC already does this for the LLVM tools.
In the 7.4.1 build, the generated settings file is a bit confused: It
locates ar in /Developer/usr/bin, but locates gcc in /usr/bin -- I believe
this comes out of the Configure process -- which without further
spelunking, I can't figure out how it gets that way, though it probably has
a lot to do with the configuration of the machine on which the distribution
for Mac is built. However, turns out that "ar command" from the settings
file doesn't appear to be used anywhere in the code base. It certainly
isn't used in SysTools.lhs, and a grep revealed only the code for setting
HP 2011.4.0.0 for Mac was also confused: The installer used the presence of
/usr/bin/gcc as the check to ensure the developer command line tools were
installed, but then the 7.0.4 ghc scripts set the preprocessor, compiler,
assembler, and linker to /Developer/usr/bin/gcc.
Finally, I believe cabal now gets it's idea of the locations of tools from
"ghc --info", so I don't think I need to dive into figuring out that as
well. Can anyone confirm? Or do I need to figure out how cabal decides
where the tools are?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cvs-ghc