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 2012.2.0.0:
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: /usr/bin /Developer/usr/bin /<xcode base>/usr/bin /Applications/Xcode.app/Contents/Developer/usr/bin 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 it. 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? - Mark
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
