OS X distribution doesn't reconfigure GHC during installation

[bgamari]

I have heard numerous reports of people installing the Platform on Darwin and ending up with broken GHC installations as the platform appears not to run configure when installaing GHC. This means that the resulting settings file doesn't reflect the system's C toolchain. For instance, one recent incident reported GHC builds failing with

clang: error: argument unused during compilation: '-nopie' [-Werror,-Wunused-command-line-argument]

After looking at ghc --info the reason becomes clear:

 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv -fno-builtin")
 ,("C compiler command","gcc")
 ,("C compiler flags"," -fno-stack-protector")
 ,("C compiler link flags"," ")
 ,("C compiler supports -no-pie","YES")
 ,("Haskell CPP command","gcc")
 ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs")
 ,("ld command","ld")
 ,("ld flags","")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","NO")
 ,("ld supports filelist","YES")
 ,("ld is GNU ld","NO")
 ,("ar command","ar")
 ,("ar flags","qcls")
 ,("ar supports at file","NO")
 ,("ranlib command","")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("cross compiling","NO")
 ,("target os","OSDarwin")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","True")
 ,("target has RTS linker","YES")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("LLVM clang command","clang")
 ,("Project version","8.4.3")
 ,("Project Git commit id","51abb1c88b53e2989a2a8c2939ac4abc04bef194")
 ,("Booter version","8.2.2")
 ,("Stage","2")
 ,("Build platform","x86_64-apple-darwin")
 ,("Host platform","x86_64-apple-darwin")
 ,("Target platform","x86_64-apple-darwin")
 ,("Have interpreter","YES")
 ,("Object splitting supported","NO")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
 ,("RTS expects libdw","NO")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Support Backpack","YES")
 ,("Requires unified installed package IDs","YES")
 ,("Uses package keys","YES")
 ,("Uses unit IDs","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("GHC Profiled","NO")
 ,("Leading underscore","YES")
 ,("Debug on","False")
 ,("LibDir","/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3")
 ,("Global Package DB","/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3/package.conf.d")
 ]

Note the value of C compiler supports -no-pie. However, the system's GCC (Clang) does not appear to support -no-pie. I suspect that configure isn't run during installation.

[gbaz]

On a current toolchain that should be a warning and not an error?

https://github.com/haskell/haskell-platform/issues/304

It looks like the user had -Werror configured on gcc which is nonstandard?

What's strange is that the platform is build on the latest toolchain, so it should be configured properly for the the standard toolchain.

That said, isn't there some work on ghc which will change this particular default in the future? not sure of the details...

[bgamari]

On a current toolchain that should be a warning and not an error?

I believe the user was building GHC and consequently it's quite likely that -Werror was set. Even so, ending up with a toolchain that isn't -Werror-safe is a bit unfortunate.

What's strange is that the platform is build on the latest toolchain, so it should be configured properly for the the standard toolchain.

It's possible that the user in question is using a slightly older toolchain.

One affected user reports clang --version of

Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

That said, isn't there some work on ghc which will change this particular default in the future? not sure of the details...

Not that comes to mind. This PIE business is just generally unfortunate.

[gbaz]

So yeah, there's more discussion on the linked ticket too. The issue would tend to be resolved by using the latest gcc/clang shipped from apple. I agree that having this configuration set and detected automatically on install would be ideal, but the last time I looked, the script to detect this was a rather scary autoconf thing, as opposed to something minimal. Further, given the whole nature of the platform, it isn't engineered to do a fresh ghc install using the installer -- rather it installs and unpacks it etc "virtually" on the build machine to be able to build associated stuff in the same env.

If there was a minimal script to tweak just that flag, I'd be open to including it in the platform. But even then, that's not perfect, because the flag will be potentially set one way, and then a user will go and update their command-line tools at some point, get a new version of clang, and then a flag might need to be set the other way again! Sigh.

[gbaz]

Honestly, I really do think it would be ideal if ghc could dynamically detect the nopie stuff on execution, since it seems like the assumption that this can be detected once-and-for-all is not a good one.

[brianhempel]

I am a teaching assistant in a university course utilizing Haskell. Multiple students attempting to install Haskell platform on their machines are running into this issue (or #304).

We point them to a workaround (editing the appropriate config file), but I thought it would be useful to note here that this is a common issue that, based on my sample, could be affecting between 10-15% of potential users.

[gbaz]

obsolete by the move to recommending ghcup on mac, which does reconfigure.