Setup.hs: /usr/bin/ar: permission denied on OS X 10.11 "El Capitan"

[notcome]

I am playing with stack. I tried to install some packages with it:

stack install parsec

But for every dependency it tried to install there was permission issue:

Setup.hs: /usr/bin/ar: permission denied

Turning on verbose mode, I saw the following output:

2015-07-11 01:59:22.455026: [debug] Run process: /Users/Selveskii/.stack/programs/x86_64-osx/ghc-7.8.4/bin/runhaskell -package=Cabal-1.18.1.5 -clear-package-db -global-package-db -package-db=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/pkgdb/ /var/folders/cp/crwr_pg55jb201td5yjg4xlc0000gn/T/stack4016/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.18.1.5/ configure --user --package-db=clear --package-db=global --package-db=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/pkgdb/ --constraint=array==0.5.0.0 --constraint=base==4.7.0.2 --constraint=bytestring==0.10.4.0 --constraint=deepseq==1.3.0.2 --constraint=ghc-prim==0.3.1.0 --constraint=integer-gmp==0.5.1.0 --libdir=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/lib --bindir=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/bin --datadir=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/share --docdir=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/doc/text-1.2.0.6 --htmldir=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/doc/text-1.2.0.6 --haddockdir=/Users/Selveskii/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/doc/text-1.2.0.6 -f-integer-simple @(stack-0.1.2.0:Stack.Build.Execute src/Stack/Build/Execute.hs:591:13)

I don't think stack was trying to write to some place it should not do. Where could the problem be? Am I using stack in a wrong way?

[borsboom]

Is it possible you ran stack with sudo the first time and ended up with some files/directories owned by root? Does this command output anything (when run in your project directory)?

find . ~/.stack -not -user $USER

[notcome]

I executed this script and it turned out that every file's owner is me. I haven't executed any sudo with stack. I am running El Capitan, which doesn't allow writing to /usr/bin but I guess stack doesn't need that permission anyway, right?

This is really strange.

[borsboom]

We haven't tested on El Capitan, so thank you for being a guinea pig! Stack should not be writing anywhere outside your home directory. Do regular cabal install commands work on this system?

[notcome]

I haven't install cabal or ghc on this system. I suppose stack can work without them? But on a similar system cabal works fine...I will give it a try anyway.

[alexbiehl]

Same with cabal install

setup-Simple-Cabal-1.18.1.5-x86_64-osx-ghc-7.8.4: /usr/bin/ar: permission denied

[notcome]

/Library/Developer/CommandLineTools/usr/bin has a copy of those utilities. Is it possible to let stack use those binaries? Is there some environment variables that can be used to achieve this?

[alexbiehl]

See haskell/cabal#2653

[notcome]

@alexbiehl I have read this. The strange part is that all files to be written is inside ~/.stack, which should have no permission issue as I have verified using the find command given by @manny-fp. Maybe there is a bug with rootless or maybe there is a deep bug with cabal as the experience of @begriffs pointed out here. No idea how to debug this though...

[alexbiehl]

Strange enough I can do this: cabal install --with-ar=$(xcrun which ar) --with-gcc=$(xcrun which gcc)

It then fails with setup-Simple-Cabal-1.18.1.5-x86_64-osx-ghc-7.8.4: /usr/bin/ranlib: permission denied.
(I haven't found which --with-PROG= parameter overrides ranlib for cabal though)

The strange thing is that xcrun which ar and which ar yield the same path, usr/bin/ar in my case.

[borsboom]

Closing this issue here since it appears to be a problem with the upstream Cabal library rather than in stack itself. Here's hoping it's resolved before GHC 7.10.2 is released so at least that works out-of-the-box on El Capitan.

[borsboom]

Actually, changed my mind and am re-opening since it looks like it may be possible to implement a workaround if that turns out to be necessary. Will watch the upstream issue and see where that's going as we get closer to a non-beta El Capitan release.