ar permission errors on OS X 10.11 El Capitan with GHC 7.8.4

[lukehoersten]

When running cabal operations, things fail with ar permission errors:

$ cabal install cabal-install
cabal: /usr/bin/ar: permission denied

This started happening after upgrading to OS X 10.11. Running with -v3 does not give any more information including the file that ar is being run on.

$ ls -al `which ar`
-rwxr-xr-x  1 root  wheel  18160 Jun  3 07:10 /usr/bin/ar

Permissions on the ar binary are fine and can be run directly with no issue. I suspect the file ar is being run on doesn't have read permissions.

[begriffs]

I encountered a similar error a year ago when building on Heroku. Although I don't remember what ultimately solved the problem, one thing you can experiment with is to copy the ar program to a new place (maybe your home directory) then pass --with-ar=/path/to/ar to the build. Just to see if the path itself somehow affects anything.

[lukehoersten]

I tried copying to my home dir and it still had the permission issue.

[lukehoersten]

OK something else is going on here: When I use the --with-ar setup it has a new error:
cabal: /usr/bin/gcc: permission denied

@begriffs seems this is more similar to your issue than I thought. Perhaps there's an issue with running commands from /usr/bin.

[iangcarroll]

/usr/bin appears read-only on 10.11.

[lukehoersten]

Doesn't look like that's the case for me:
drwxr-xr-x 1068 root wheel 36312 Jun 8 19:31 bin

Also, I'm able to run ar directly just fine. Same with gcc.

[Codas]

/usr/bin/ar also seems to be affected by the new rootless "feature" introduced in 10.11. sudo chmod +x /usr/bin/ar (just as an example) says I do not have the permissions to modify this file.

However, disabling rootless (sudo nvram boot-args="rootless 0") does not solve the issue with cabal...

[lukehoersten]

Weirdly I was unable to move the binary with sudo. Is this a part of rootless as well? I've not yet heard of this feature.

[samfoy]

@Codas, are you sure that rootless really got disabled? there has been a bug with disabling it.

[Codas]

You were right, rootless was not disabled as I thought it was. The problem is that sudo nvram boot-args="rootless 0" should really be sudo nvram boot-args="rootless=0".

Now everything seems to be working as expected.

[lukehoersten]

sudo nvram boot-args="rootless=0" worked for me as well. So we know what the problem is but now, how to fix this?

[uchuugaka]

You have to build to install using components that do not require root access. (and/or file a bug with Apple)

[lukehoersten]

@uchuugaka can you be more specific about what you mean by "build to install using components that do not require root access"?

[uchuugaka]

Simply disabling rootless isn't enough for everything. Many projects are waking up to realizing they need to find new places they can put things. Directories that are not locked down. I'm still looking into it. macports for example is finding they may need a new directory as their root.

[lukehoersten]

@uchuugaka Disabling rootless is only a workaround until a real fix is implemented. It doesn't sound like filing a bug with Apple is appropriate at this point.

[megamaddu]

sudo nvram boot-args="rootless=0" did the trick for me on 10.11, but I'm not sure if it was a good idea.. haha

[PupaRebbe]

i had a problem making an alias for X11 in /usr, disabling rootless solved my problem, thanks all

[lukehoersten]

Rootless: Bans writing to /System, /usr, /bin, /sbin - So far /usr/local isn't write-protected.

Homebrew has to contend with the same thing: Homebrew/legacy-homebrew#40837

[alexbiehl]

I don't understand how write-protection is preventing ar and gcc from being invoked, since we want to execute, not write. Can someone elaborate?

[notcome]

It is strange that cabal install cabal-install works fine on my El Capitan but when I used stack it reported a similar error (see the issue mentioned by @alexbiehl ). Can you give me details about your settings @lukehoersten ?

[lukehoersten]

@notcome settings for what in particular?

[phadej]

@lukehoersten which cabal version do you use / how you installed it (Haskell Platform, directly from binary?). I could try to reproduce and investigate this issue this week, as I get another mac to install El Capitan to.

[lukehoersten]

Confirmed this is still an issue on the 10.11 Beta (15A216g) version of El Capitan (beta 2):

$ cabal --version
cabal-install version 1.22.4.0
using version 1.22.2.0 of the Cabal library 

[notcome]

@lukehoersten It's strange that I cannot reproduce this error. I am using v1.22.0 and El Capitan 15A216g. But when I tried stack a similar error happened. Which version of GHC are you using?

stack + ghc 7.8.4 => permission error
ghc 7.10.1 + cabal 1.22.0 => everything works fine

[lukehoersten]

ghc 7.8.4 for me. This could be the problem here. Can you try cabal w/ 7.8.4 and see if you can reproduce?

[notcome]

That's the problem:

➜  ~  export PATH=/Users/LiuMS/Downloads/ghc-7.8.4.app/Contents/bin:/Users/LiuMS/.cabal/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/usr/local/FDK/Tools/osx
➜  ~  $PATH
zsh: no such file or directory: /Users/LiuMS/Downloads/ghc-7.8.4.app/Contents/bin:/Users/LiuMS/.cabal/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/usr/local/FDK/Tools/osx
➜  ~  ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.8.4
➜  ~  cabal install text
Resolving dependencies...
Configuring text-1.2.1.1...
Failed to install text-1.2.1.1
Build log ( /Users/LiuMS/.cabal/logs/text-1.2.1.1.log ):
[1 of 1] Compiling Main             ( /var/folders/f2/wgwjk8g552d7wch372rh_tq00000gn/T/text-1.2.1.1-2953/text-1.2.1.1/dist/setup/setup.hs, /var/folders/f2/wgwjk8g552d7wch372rh_tq00000gn/T/text-1.2.1.1-2953/text-1.2.1.1/dist/setup/Main.o )
Linking /var/folders/f2/wgwjk8g552d7wch372rh_tq00000gn/T/text-1.2.1.1-2953/text-1.2.1.1/dist/setup/setup ...
Configuring text-1.2.1.1...
setup-Simple-Cabal-1.18.1.5-x86_64-osx-ghc-7.8.4: /usr/bin/ar: permission
denied
cabal: Error: some packages failed to install:
text-1.2.1.1 failed during the configure step. The exception was:
ExitFailure 1

[phadej]

The issue is probably the same as in: haskell/unix#18

 5545/0x5266:  stat64("/usr/bin/ar\0", 0x102E34370, 0x0)                 = 0 0
 5545/0x5266:  access("/usr/bin/ar\0", 0x4, 0x0)                 = 0 0
 5545/0x5266:  access("/usr/bin/ar\0", 0x2, 0x0)                 = -1 Err#1

[phadej]

I installed ghc-7.8.4 from haskell.org site, and it has unix-2.7.0.1 package, the issue is fixed in 2.7.1.0. Could @notcome and @lukehoersten verify, i.e. check their package databases.

According to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory there is no way to use 7.8.4 on El Capitan, except if you do special build with bumped unix package.

EDIT I installed binary GHC 7.10.1 and cabal-install, cannot reproduce with that configuration.

[carlosacp]

running

$ stack install cabal-install
…
$ hash -r

from ghcformacosx/ghc-dot-app#41

fix

[dagit]

Documenting my solution here for future generations:

1. Install both ghc 7.8.4 and ghc 7.10.x, but below I assume ghc defaults to 7.8.4. That is the case on my system because I installed 7.8.4 more recently than 7.10.x.
2. cabal update && cabal unpack process directory unix
3. go into each of those packages (the order I used was directory, then unix, then process) and type ghc-7.10.x --make Setup.hs && ./Setup configure --with-ghc=ghc-7.8.4 && ./Setup build --with-ghc=ghc-7.8.4 && ./Setup copy && ./Setup register. The goal of that command is to use 7.10 to build Setup.hs but then use ghc-7.8.4 to build/register the packages. You'll know you've done it correctly when ghc-pkg-7.8.4 list | grep unix lists 2.7.1.0.
4. cabal install Cabal
5. use ghc-pkg-7.8.4 describe Cabal to make sure it depends on the correct version of unix (needs to be at least 2.7.1.0).

At this point I was able to use 7.8.4 as normal.

Thanks to @glguy for suggesting the trick with Setup.hs.

[nrolland]

@dagit future generations will be proud of us struggling haskellers

[mcandre]

+1

[mcandre]

Workaround:

$ brew update
$ brew upgrade ghc
$ brew unlink cabal-install
$ brew install cabal-install --constraint=unix>=2.7.1.0
$ brew link --overwrite cabal-install

System:

$ specs haskell os
specs haskell os
specs --version
0.21

cabal --version
cabal-install version 1.20.0.3
using version 1.20.0.2 of the Cabal library 

ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3

system_profiler SPSoftwareDataType | grep 'System Version'
    System Software Overview:
      System Version: OS X 10.11.2 (15C50)
      System Integrity Protection: Enabled

[backus]

Thanks @mcandre that worked for me

[creswick]

@dagit and @mcandre 's solutions both seemed to work for me, until I tried to install something with a custom Setup.hs (I think). eg: HDBC-postgresql-2.3.2.3, which failed with the ar problem.

[dagit]

@creswick What is the output of ghc-pkg-7.8.4 describe Cabal on your system? If their Setup.hs pulls in the wrong version of unix that could explain the failure there.

[creswick]

@dagit

It's ~500 lines, so I made a gist: https://gist.github.com/creswick/9489a197d93bb6f009f8

[23Skidoo]

@creswick Yes, it looks like the version of Cabal you have installed is built against unix-2.7.0.1. The issue was fixed in unix-2.7.1.0.

[creswick]

@23Skidoo @dagit thanks! This seemed to work:

$ cd && cabal --no-require-sandbox install Cabal --reinstall --force-reinstalls

[Blaisorblade]

Trying to do this now, without ever disabling SIP. I'd guess disabling SIP, upgrading unix and Cabal in the global database and reenabling SIP is easiest, but involves rebooting, so I plan using this: #2653 (comment).

| tried other solutions but had trouble:

@gbaz wrote:

If you're using ghc for mac os x, you can download the fixed cabal binary from here: https://www.dropbox.com/s/rvvjlcmd85yyvy5/cabal?dl=0

Thanks, but that's not enough, because one also needs a fixed Cabal in the package database.

@mcandre wrote:

$ brew install cabal-install --constraint=unix>=2.7.1.0

brew ignores constraints, and without quotes the > is read as a shell redirection. At least that will typically give a prebuilt working cabal-install binary.

@phadej wrote:

You are correct. I'm a bit confused: Sometimes, when cabal configures the package, it builds a setup program, using Cabal the-library (not the one it's built against, but the one which is in the package database) sometimes it doesn't.

I think the "sometimes" might depend on ~/.cabal/setup-exe-cache/, which caches prebuild default Setup.hs — I have setup-Configure-Cabal-1.18.1.5-x86_64-osx-ghc-7.8.4 in there, still built using the wrong unix version.

[gbaz]

Thanks, but that's not enough, because one also needs a fixed Cabal in the package database.

Isn't it enough to just install the cabal binary (you can get it here now btw: https://www.haskell.org/cabal/release/cabal-install-1.24.0.0/cabal-install-1.24.0.0-x86_64-apple-darwin-yosemite.tar.gz ) and then install the Cabal library using that binary?

[Blaisorblade]

I got this working with @dagit's suggestion (with slight changes)!

Corrections:

• I checked with cabal install unix Cabal --global --dry-run that the plan involved no reinstalls.
• Following that plan, I installed unix, directory, then process
• Following other tips, I installed Cabal globally to be able to use Stack.
• if you use Stack, you must override in extra-deps the versions of unix, Cabal, directory and process. They need not be the ones you installed (the package you’re building might dislike that); but none can match the ones shipped with GHC, because even Stack can’t cope with two versions of the same package with different dependencies.
• I had GHC 8.0.1 instead of 7.10 around, and it still worked — though building Cabal felt slow as hell when I watched (probably still reasonable though).

cabal unpack process directory unix
newver=8.0.1
for i in unix directory process; do
  (cd $i-* && ghc-$newver --make Setup.hs && ./Setup configure --with-ghc=ghc-7.8.4 && ./Setup build --with-ghc=ghc-7.8.4 && ./Setup copy && ./Setup register)
done
cabal install Cabal --global

Output w/ versions:

$ cabal install unix Cabal --global --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
unix-2.7.2.0
directory-1.2.6.3
process-1.4.2.0
Cabal-1.24.0.0
$ cabal unpack process directory unix
Downloading process-1.4.2.0...
Unpacking to process-1.4.2.0/
Downloading directory-1.2.6.3...
Unpacking to directory-1.2.6.3/
Unpacking to unix-2.7.2.0/

[Blaisorblade]

Isn't it enough to just install the cabal binary and then install the Cabal library using that binary?

@gbaz Not quite (for me and with the previous binary), because the Setup binary would link against the existing unix library. That's even if you install unix and then Cabal, the setup of unix fails—I tried.

It might help if you had a newer version of unix already installed even in the user database (or if you install the newer Cabal with SIP disabled, but I'll trust you didn't miss that), but I did this from scratch with a GHC from https://ghcformacosx.github.io/.

[Blaisorblade]

@gbaz I partially retract; your suggestion might work with cabal-install 1.24 (not the Dropbox version) because it includes 03b02fb, fixing #2633, as @phadej earlier explained. I haven't tried, but based on #2653 (comment) it should work.

EDIT: it worked, as long as I install unix too with cabal install unix Cabal --global. Thanks!