clang: error: unknown argument: '-no-pie' on darwin macOS High Sierra 10.13.4

[jcrben]

Installed haskell-platform via homebrew cask; brew cask info haskell-platform reports haskell-platform: 8.4.2

This is an open question on Stackoverflow (as well as other places). I followed https://stackoverflow.com/a/50419101/4200039 in part and fixed it by replacing
, ("C compiler supports -no-pie","YES")
with
, ("C compiler supports -no-pie","NO").

It seems this is something of a known issue based on #272 (comment), but it seems to be broken by default on macOS unless I've got something weird about my system...

[gbaz]

Which version of gcc and os x do you have installed?

[jcrben]

OSX version is in the subject line, but even more precisely: 10.13.4 (17E199)

I also tried doing it with PATH=/usr/local/opt/llvm/bin:$PATH at which point my shell reports:

Does GHC not work with clang? Also was expecting this to be pretty much self-contained. Did I miss some caveats? https://github.com/Homebrew/homebrew-cask/blob/master/Casks/haskell-platform.rb

[gbaz]

So the problem seems to be that you have two versions of clang lying around? One supports/requires the no-pie flag (the one shipping with xcode and run as gcc) and one does not recognize it (the one from brew). The config file installed by the platform expects it to be configured for the standard xcode toolchain. Given the way ghc is setup, it doesn't autodetect at every run, it just is configured once and forall. So we can't have it defaulted both ways.

I think forthcoming ghcs won't require use of the flag anymore (not sure of the details) in which case this will no longer be an issue, but until then I don't know of a solution other than changing the config by hand. I'd be happy with a PR that put the suggestion in a discoverable place on the site, but not on the "hot path" of standard instructions since this requires using a nonstandard compiler (or ancient version of xcode tools) to encounter.

[jcrben]

One supports/requires the no-pie flag (the one shipping with xcode and run as gcc)

Are you sure? I get this error when the the system gcc has precedence in my PATH - that homebrew LLVM clang (in /usr/local/opt/llvm/bin) isn't actually in my PATH.

I'm not actually sure that there are two gcc commands on my system - there's just the /usr/bin/gcc one as far as I know. I just uninstalled my homebrew gcc and llvm (with --force to remove old versions) and get the same error.

That stackoverflow question is quite recent. xcode-select --version reports 2349. Maybe Apple changed something? After xcode-select -r same error.

The GNU gcc compiler that I had installed had a versioned executable:

I also use the nix package manager but I don't have gcc or clang installed with it.

[gbaz]

Ok a bit more investigation reveals that there was an os-x toolchain change:

https://ghc.haskell.org/trac/ghc/ticket/15112

However, that appears to just give a warning about unused arguments, not an error (I confirmed this on my system as well).

[jcrben]

According to nh2/link-with-lld-example#1 (comment) llvm supports -no-pie in llvm/clang 5 but according to https://news.ycombinator.com/item?id=16545037 (uncited by AlexeyBrin) Xcode 9 is based upon llvm/clang 4

[gbaz]

(btw note that the clang version I have, which I believe is the latest, is slightly newer than that which you report: Apple LLVM version 9.1.0 (clang-902.0.39.2))

[jcrben]

Ah good point. I tend to ignore the App Store - there's an Xcode update waiting for me (installing). But I did have the latest Command Line Tools update. Seems like I should have the latest.

I wonder if you're on the Beta or Developer channel from Apple.

Thanks for finding the toolchain change. I guess things will work themselves out.

I particularly got the error when trying to run cabal install strict (copying marcusbuffett/Clanki#5 (comment)) - perhaps cabal in particular isn't happy.

[gbaz]

Ok so it sounds like this is just a stray warning and a red herring that will hopefully be sorted out soon, and the actual install issue you encountered was something else. Closing on that basis. Thanks for bearing with the investigation -- its good to know what this is if it arises in the future...

[aleith]

Same kinds of issues on macOS Sierra 10.12.6,
Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin16.7.0
The Glorious Glasgow Haskell Compilation System, version 8.4.3

Alastairs-15-MBP:applied-fp-course aleith$ cabal sandbox init
Writing a default package environment file to
/Users/aleith/dev/applied-fp-course/cabal.sandbox.config
Creating a new sandbox at /Users/aleith/dev/applied-fp-course/.cabal-sandbox
Alastairs-15-MBP:applied-fp-course aleith$ cabal install --only-dependencies --enable-tests
clang: error: unknown argument: '-no-pie'
'gcc' failed in phase `C Compiler'. (Exit code: 1)
Alastairs-15-MBP:applied-fp-course aleith$ cabal build
Resolving dependencies...
Warning: solver failed to find a solution:
Could not resolve dependencies:
[__0] trying: applied-fp-course-0.1.0.0 (user goal)
[__1] unknown package: warp (dependency of applied-fp-course)
[__1] fail (backjumping, conflict set: applied-fp-course, warp)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: applied-fp-course, warp
Trying configure anyway.
Configuring applied-fp-course-0.1.0.0...
cabal: Encountered missing dependencies:
aeson ==1.,
http-types >=0.9 && <0.13,
optparse-applicative >=0.13 && <0.15,
semigroups ==0.18.,
sqlite-simple ==0.4.,
sqlite-simple-errors ==0.6.,
wai ==3.2.,
warp ==3.2.

Does this mean the initialisation failed? Not sure why I need cabal and what it does, I cloned the QFPL Applied Functional Programming Course and trying to get started. .

[retnuh]

I'm also getting this error on MacOS 10.12.6:

bash-3.2$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
bash-3.2$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.2
bash-3.2$ uname -a
Darwin shank.local 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64

I get an error (not a warning) trying to install anything w/ cabal:

bash-3.2$ cabal install lambdabot
clang: error: unknown argument: '-no-pie'
`gcc' failed in phase `C Compiler'. (Exit code: 1)
bash-3.2$ cabal install hoogle
clang: error: unknown argument: '-no-pie'
`gcc' failed in phase `C Compiler'. (Exit code: 1)

I'm just learning haskell so am not familiar with the toolchain, or what config file I need to edit to work around this...

[gbaz]

The current version of gcc/clang shipped by apple is newer:

gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.2)

It should be possible to upgrade xcode and the command line tools to the latest.

[gbaz]

To work with an older clang, the fix is to change settings as described in the SO answer linked in the top of this ticket: https://stackoverflow.com/questions/50386787/cabal-install-gcc-failed-in-phase-c-compiler/50419101#50419101

Note that the path to the settings may vary a bit depending on the ghc version you have installed.

[retnuh]

It seems to me that at least some of these settings should be configured at install time, rather than build time? It's not reasonable to expect people to have to install the latest XCode to install haskell, particularly when it requires registration on Apple's site, etc, etc.

[gbaz]

It would be nice to do that, yes, but that isn't how the platform is built, and it would take a lot of work to do that. There's a separate ticket discussing that as future work. In the meantime, the advice above should be sufficient to unblock you or solve your issue?

I do think it is reasonable to assume that people procure the latest developer tools to install GHC, since currently that does not require developer registration, just the basic registration you need to update any of apple's installed tools, no? Further, upgrading basically requires opening the app store, and clicking on the "updates" button that apple asks you to click on, no?

e.g.

(in fact, apple is rather irritating about bugging you until you do update)

[retnuh]

I was able to proceed by editing the file, thanks. I'm still not sure that expecting people to upgrade their OS and/or install the entire XCode tool chain just to get haskell to work is going to be very successful. Many people will just give up. FWIW, when I go to the app store it's not asking me to upgrade XCode or the command line tools. I don't have XCode installed - nor do I plan on installing it.

[gbaz]

So where do you get clang from?

[ezyang]

Ran into this today; I have my clang pinned to an older version because some other tools I use (nvcc) don't support newest clang. FYI.

[gbaz]

Hmm... I wonder if despite detecting no-pie support in the latest, we can still turn it off and have it work with current clang? If so, a re-release of the platform with it unilaterally off sounds like the simplest short term solution. @bgamari do you have a suspicion if this is reasonable or not?

[aleith]

It should be possible to upgrade xcode and the command line tools to the latest.

Easier said than done on Sierra 10.12.6 (I have a good reason for sticking to Sierra, the volume format change from HFS to APFS in 10.13.0 mean some apps like Disk Carrier don't work at all until DW is updated for High Sierra/APFS).

If you go to Mac App Store in Sierra to download Xcode, you get a notification that it will download an older version, which turns out is 9.0. But then you can update it to 9.2. Iff you go to Apple's developer site it's ambiguous which Command Line and Additional Tools are a match for Sierra. Currently my gcc version: Apple LLVM version 9.0.0 (clang-900.0.39.2) Not sure why when I have Xcode 9.2 now.

[gbaz]

Fair 'nuff. I just tested and things still work with the flag off, even with latest tools, as far as I can tell. So I think the proper thing is a mac re-release that has the flag tweaked. I'll try to put that together in the next few days -- ideally the way to do so is just repackage and resign the installer rather than do a full rebuild, but either way it looks to be a bit of a pain to work around..

[aleith]

Does it mean cabal is not installing or is at a non-relevant error?

[gbaz]

I dont understand the question?

[gbaz]

To clarify -- what happens is the platform installs a ghc settings file configured to pass a certain flag (no-pie) to gcc, because it is built on a system that detects that gcc can take the flag.

But gcc does not need the flag, it appears, even with the latest clang. So we should be able to unconditionally never pass the flag on os x, and that should be fine. As such we can then prepare a distribution that works across all clang/xcode versions on os x, just by keeping the no-pie setting at NO uniformly. That's what I'm proposing we do.

[aleith]

What is the error message referring to? To what extent does this affect the GHC(i) install operations.

[aleith]

Ah, so it has no real world impact on using GHC?

[gbaz]

@aleith on your specific build issue, have you followed the linked instructions to modify the settings file? That should solve your specific issue.

The error message is a failed build, and it appears the build is failed because you have an old clang. But that's fine -- you can just modify the settings file as described in https://stackoverflow.com/questions/50386787/cabal-install-gcc-failed-in-phase-c-compiler/50419101#50419101 and you'll be ok, even with the prior version of clang. I suggest you do that.

[aleith]

Ok will attempt that when I get a chance, thx.

[retnuh]

@gbaz thanks that sounds like a good plan, thanks. I installed the xcode command line tools way back when I installed homebrew - I don't remember the exact setup, but it was just the minimum install, and I'm not being warned/told that it needs updating.

@aleith the error prevents cabal from building/installing anything on the affected systems, so pretty high impact 😄

[pzp1997]

Any updates or workarounds? Would installing an older version of haskell-platform help?

[gbaz]

This works fine as long as you have the up-to-date developer tools from apple including the latest clang. If for some reason you can't update to the current versions of the apple devtools, you can update your settings as described in https://stackoverflow.com/questions/50386787/cabal-install-gcc-failed-in-phase-c-compiler/50419101#50419101

[mouse07410]

Please change the defaults for MacOS

• from gcc to clang, and
• from -no-pie required YES to -no-pie required NO

That's the current Xcode default, and ghc-8.4.3 works with these changes OK (MacOS High Sierra and Mojave). While with the current defaults - I have to manually change them before I can get anything sensible from GHC.

Update:

This works fine as long as you have the up-to-date developer tools from apple including the latest clang

This is not correct - it failed to work with Xcode-10.1. @gbaz I urge you to update the default settings for the MacOS Haskell distribution.

[joswr1ght]

If you installed Cabal with brew, you will need to edit the file /usr/local/Cellar/ghc/8.4.4/lib/ghc-8.4.4/settings, changing:

("C compiler supports -no-pie", "YES"), to

("C compiler supports -no-pie", "NO"),

[mouse07410]

I for one install Cabal as a part of Haskell Platform - i.e., Haskell Platform installs GHC, Cabal, stack, and plenty of other things.

It is possible to locate the settings file and manually edit it (and I've done it to get GHC and Cabal working on my Mac) - but the Haskell Platform distro and the brew recipe should take care of that for me, IMHO. It shouldn't be end-user's responsibility to manually edit packages like this.

[gbaz]

The defaults are the ones ghc autodetects and configures on an up-to-date os-x install.

The problem is that we configure on the platform build machine, but thanks to brew people may have other settings that are nonstandard and need to be corrected.

So there are two courses of action here. First, we're intending to move away from prepackaged platform installers on os x and to using the ghcup tool, which will configure in whatever env users have. Second, if people don't like how ghc configures things on os x, they should file a ticket with the ghc tracker directly.

[retnuh]

To be honest, many people using the haskell-platform are going to be new to haskell. It's a bad experience saying "go edit this config file because we haven't configured our install process correctly. Oh and if you don't like it, go file a ticket against the specific component, it's nothing to do with us."

New people aren't going to know which component doesn't work. The people working on the haskell-platform project do. It makes sense that they open the relevant tickets and coordinate. New people are just going to be turned off and say "forget this, the so-called nice all in one installer package doesn't even work, I'm not going to bother."

I also think that if haskell-package claims to work for OSX, then it should work for the various different setups without manual intervention. If that's not possible, then there should be different releases on OSX for the different scenarios.

I'm interested in haskell, and I appreciate the hard work people have done over the years, including the work on the haskell-platform. But I have struggled big time to get a working environment going on OSX, and I generally know what I'm doing. I imagine many others would have bailed at this point.

[gbaz]

Indeed, that's why as I wrote above: "we're intending to move away from prepackaged platform installers on os x and to using the ghcup tool, which will configure in whatever env users have."

That should resolve this issue.

If there are any issues about how ghc detects and configures envs in general, that go beyond this, then those are issues to be filed against ghc.

[mouse07410]

The defaults are the ones ghc autodetects and configures on an up-to-date os-x install.
The problem is that we configure on the platform build machine

Unfortunately, this is mostly useless because your build machine does not (and cannot) reflect what a user would likely have.

but thanks to brew people may have other settings that are nonstandard and need to be corrected

It's not just brew. We all know that a lot of useful stuff on MacOS comes via 3rd-party package managers, of which there are quite a few: brew, Macports, Fink, several more. They all use different conventions, AFAIK.

The implication of the above is - since you cannot run configuration for all of the above, you should offer users a way to adjust configuration in a more convenient way than searching for the settings file and manually editing it.

"...using the ghcup tool, which will configure in whatever env users have..."

Is this what I was asking above? A tool that would run on a user's machine, figure out how it's configured, and write its findings into settings file or such?

[gbaz]

Is this what I was asking above? A tool that would run on a user's machine, figure out how it's configured, and write its findings into settings file or such?

Yes, exactly. It would replace the current platform installer as the recommended way for os x, as it already has for linux: https://github.com/haskell/ghcup

That path configures on the end-user's machine as part of the ghc-install process, and so detects the configuration on the user's machine rather than pinning the config to the machine that the current binary installation is built on.