Cabal: `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.

[spicydonuts]

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: https://github.com/Homebrew/homebrew/issues/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: https://github.com/haskell/unix/pull/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.

[lukehoersten]

Confirmed using --constraint=unix>=2.7.1.0 fixes the issue with rootless. Congrats on figuring this out. So I can confirm ghc-7.8.4 works when building cabal-install with --constraint=unix>=2.7.1.0.

Is there a 7.8.4 binary for cabal-install "batteries-included" packages should switch to?

[lukehoersten]

@phadej how do we make a new cabal-install binary release w/ the latest unix?

[phadej]

I built cabal-install from not so old master (which includes https://github.com/haskell/cabal/pull/2633) on _Yosemite_. Using that binary I can install newer unix-2.7.1.0 and Cabal with

cabal install unix Cabal --global

on _El Capitan_ with GHC 7.8.4. Using that cabal-install I can finally operate normally.

Installing into global database is important to make e.g. stack work, as it doesn't use user database.

---

The patch mentioned is required, otherwise cabal-install will compile setup using old unix, so even cabal-install itself uses newer one, things don't work.

---

And this makes next to impossible to bootstrap Haskell on _El Capitan_ with _GHC 7.8.4_ (you need older osx and there quite many steps). I'd advice to start using _7.10.x_ there and leave _7.8.4_ builds (including stackage lts-2) for Travis or other linux boxes.

[lukehoersten]

Some are unable to move to 7.10.x (including myself) due to a handful of reasons. For me there's a 4x performance degradation between 7.8.4 and 7.10.1. If we can produce a new 7.8.4 cabal-install binary then the ghcformacosx project can repackage with that.

[phadej]

@LukeHoersten the binary doesn't solve anything. It's important to have Cabal (_the-library_) package build against newer unix in the global database (not cabal binary from cabal-install, _the-tool_).

[lukehoersten]

Are you sure it's not both the library and the binary? The binary is usually statically linked against haskell libraries. ghcformacosx, for example, only ships with cabal-install the binary and since it's statically linked against the wrong unix you can't bootstrap up to a later version.

[phadej]

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.

The patch https://github.com/haskell/cabal/pull/2633, makes cabal-the-tool to work as external setup method when possible, if I understand it right.

And again if my understanding is correct, currently:

• cabal uses _the library_ when used externally (to build dependencies)
• and itself - _the tool_, when used internally (to build a package you are in)

So it might be possible to fetch all dependencies and build them by hand, but that's quite a job.

[lukehoersten]

According to https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535, a properly compiled binary cabal-install is all that's needed.

[phadej]

Shortly: No GHC 7.8 for El Capitan. https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport

Thus there are no other ways to solve this issue, other than disabling rootless (instructions in the link or above in the thread). Thus this can be closed.

[lukehoersten]

Makes sense to focus efforts on 7.10.1. Thanks for your help @phadej

[danfran]

I have installed GHC 7.10.2 for El Capitan and I am having same issue:

cabal: /usr/bin/ar: permission denied

[nrolland]

@danfran hitting this for 7.8.4, as expected, will move to 7.10, please report if you find a solution

[gbaz]

@danfran you should not have this issue under 7.10.2 if you are using an officially released cabal binary. If you are using ghcformacosx then see this ticket https://github.com/ghcformacosx/ghc-dot-app/issues/41 and in particular the cabal binary packaged there.

[mgadda]

Is there a separate ticket (seeing that this is closed) tracking the repair of Cabal/GHC 7.10.2 with OS X 10.11? Is it #2851? It's definitely still an issue (at least using the cabal bundled with Haskell Platform).

[gbaz]

@mgadda I don't know of any issues with cabal and the current platform? The only issue I know of is the need to change the install script, for which there is a candidate installer for the platform already produced. If you have any other issue, feel free to make a not of it on that ticket for now, I suppose.

[mgadda]

@gbaz Oh I didn't realize there was a candidate installer out there. Where is that?

[gbaz]

Just added a comment to point to it at https://github.com/haskell/haskell-platform/issues/221

[michaelgwelch]

I just installed the Haskell Platform 7.10.2-a for OS X 10.11 It's the second download at the download page

I'm seeing the issue reported in this thread:

$ cabal install --dependencies-only --enable-tests
cabal: /usr/bin/ar: permission denied

Just to be clear this is the one I downloaded

[michaelgwelch]

I'm not sure what is going on. If I run which cabal, I see it's running cabal from ~/Library/Haskell/bin/cabal If I explicitly run /Library/Haskell/ghc-7.10.2-x86_64/bin/cabal install --dependencies-only --enable-tests then it appears to be working.

Both locations show new directories that were added today (when I installed using the new install for 10.11) I'm not sure what should be installed where, or symlinked to other locations.

I guess I can install and make sure I don't have cabal or the rest of the binaries anywhere on my machine and then reinstall.

UPDATE: I checked my .bash_profile and I see that for some reason at some time I added $HOME/Library/Haskell/bin to my path. I assume if I remove that this will fix my problem. Yes, that did resolve my issue.

[gbaz]

Yes, I think that's correct. We should probably warn against that issue -- I think prior platforms added that back in the past before the current symlink approach. Thanks for the feedback!

[michaelgwelch]

@gbaz just to follow up, now when I type which cabal I do see it's running usr/local/bin/cabal as expected and that is symlinked to the location in /Library/Haskell that I mentioned above. Everything looks good.

[edsko]

For the benefit of other people finding this thread: no idea why, but the nvram invocation did not solve the problem for me; disabling system integrity protection in recovery mode however did.

[dogweather]

So for someone new to Haskell on the Mac (e.g. me), what should one do?

I hit this error after installing http://ghcformacosx.github.io/ and then running cabal run in a project folder.

[gbaz]

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

You can also run stack install cabal-install apparently, to build your own fixed cabal.

The ghcformacosx ticket tracking this is here: https://github.com/ghcformacosx/ghc-dot-app/issues/41

Also note that the current haskell platform ships the proper cabal.

[nrolland]

Hi, if you are a newcomer I would really advise you to use stack as it pins
down more things, and does not pollute global environment.

On Friday, November 6, 2015, Robb Shecter [email protected] wrote:

So for someone new to Haskell on the Mac (e.g. me), what should one do?

I hit this error after installing http://ghcformacosx.github.io/ and then
running cabal run in a project folder.

—
Reply to this email directly or view it on GitHub
https://github.com/haskell/cabal/issues/2653#issuecomment-154253897.

Nicolas Rolland
mobile : [phone]

[adinapoli]

My experience was the same as @edsko : Disabling SIP in recovery mode (following the guide he posted) solved the issue for me.

[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: https://github.com/haskell/cabal/issues/2653#issuecomment-163337653.

| 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 03b02fb6ef23988543bda937bda029262ebbaf17, fixing #2633, as @phadej earlier explained. I haven't tried, but based on https://github.com/haskell/cabal/issues/2653#issuecomment-122045814 it should work.

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