Stack: 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 https://github.com/haskell/cabal/issues/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.

[notcome]

cabal install parsec works fine on my Mac.

[notcome]

I just realized maybe I could adjust $PATH. However, it seemed that Apple had thought about this—I put a fake clang to /usr/local/bin and put this directory before /usr/bin in $PATH but the true one in /usr/bin is still called anyway.

[notcome]

It seems to be a problem of GHC 7.8.4. See updates here. We just need to await GHC 7.10.2 out and use it on El Capitan 😂. By the way, is it possible to force stack to use GHC 7.10.1 right now?

[borsboom]

The GHC version is determined by the resolver setting in stack.yaml. lts-2.x resolvers will always use GHC 7.8, but lts-3.x (when it is released) will use GHC 7.10. Recent nightly snapshots use GHC 7.10.

[phadej]

As I commented on cabal issue the problem is most likely in unix package.

I don't know what we can do with this. Either ask ghc maintainers to make ghc 7.8.5 with only unix version bumped (it's only minor bump), or just wait until _LTS-3_ with _ghc-7.10_ is available.

_EDIT_ building with nightly snapshot seems fine.

[borsboom]

Is someone who has El Capitan to test with willing to try building stack with a newer version of the unix package as suggested in the cabal issue? (not sure if I'm reading the issue right, maybe that won't make a difference since stack shells out to runhaskell Setup.hs anyway)

[notcome]

I could do it tonight, seven/eight hours later.

在 2015年7月16日，12:31，Emanuel Borsboom [email protected] 写道：

Is someone who has El Capitan to test with willing to try building stack with a newer version of the unix package as suggested in the cabal issue?

—
Reply to this email directly or view it on GitHub.

[phadej]

@manny-fp the issue is that stack uses Cabal/unix in the global database (AFAIK), when compiling packages.

Example after steps in https://github.com/haskell/cabal/issues/2653#issuecomment-122045814

2015-07-16 19:41:19.613858: [debug] Run process:
/Applications/ghc-7.8.4.app/Contents/bin/runhaskell -package=Cabal-1.22.4.0
-clear-package-db -global-package-db
-package-db=/Users/ogre/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/pkgdb/
/var/folders/cz/h9qdw_8d6fb8hzqzcmc99s000000gn/T/stack80545/Setup.hs
--builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/ configure --user
--package-db=clear --package-db=global
--package-db=/Users/ogre/.stack/snapshots/x86_64-osx/lts-2.17/7.8.4/pkgdb/
--package-db=/Users/ogre/fum2github/.stack-work/install/x86_64-osx/lts-2.17/7.8.4/pkgdb/
--dependency=base=base-4.7.0.2-918c7ac27f65a87103264a9f51652d63
--dependency=transformers=transformers-0.3.0.0-6458c21515cab7c1cf21e53141557a1c
--libdir=/Users/ogre/fum2github/.stack-work/install/x86_64-osx/lts-2.17/7.8.4/lib
--bindir=/Users/ogre/fum2github/.stack-work/install/x86_64-osx/lts-2.17/7.8.4/bin
--datadir=/Users/ogre/fum2github/.stack-work/install/x86_64-osx/lts-2.17/7.8.4/share
--docdir=/Users/ogre/fum2github/.stack-work/install/x86_64-osx/lts-2.17/7.8.4/doc/spdx-0.2.0.0
--htmldir=/Users/ogre/fum2github/.stack-work/install/x86_64-osx/lts-2.17/7.8.4/doc/spdx-0.2.0.0
--haddockdir=/Users/ogre/fum2github/.stack-work/install/x86_64-osx/lts-2.17/7.8.4/doc/spdx-0.2.0.0
@(stack-0.1.2.0:Stack.Build.Execute src/Stack/Build/Execute.hs:591:13)

Notice -package=Cabal-1.22.4.0 -clear-package-db -global-package-db

So somehow you have to get _good_ Cabal into global database, after that stuff works.

[borsboom]

So from today's HWN it sounds like the GHC team is not planning to release a bugfix for ghc-7.8, and I think we'll have to follow their lead (anything else would require an ugly workaround of installing a different Cabal library -- not impossible, but but probably not worth doing, unless somebody feels like making a PR). This can be worked around by disabling rootless mode on El Capitan (HWN includes instructions).

It sounds like ghc-7.10.1 should already be working on El Capitan. Has anyone tried stack with ghc-7.10.1 (e.g. with a recent nightly snapshot) on El Capitan? I'm curious if the current binaries (build with ghc-7.8.4) work, or if it will require building a new stack binary with ghc-7.10.x.

[phadej]

stack binary works perfectly on El Capitan + ghc-7.10.1. stack uses system Cabal (thru runhaskell Setup.hs) to actually build the packages, thus no problems.

[borsboom]

Ok, thanks, that's what I thought but just wanted someone to confirm it by actually trying it.

[katrielalex]

Would it be possible to fail fast if stack tries to install ghc < 7.10 on El Capitan? (It would be much nicer to have a sane error message, since as stated above this won't be fixed.)

[borsboom]

We shouldn't blanket-disallow 7.8.4 on El Capitan, since some people may disable rootless mode. So if we want it to fast-fail, it should be done by performing a test that will fail if rootless is enabled, rather than just checking the OS version. A pull request would be appreciated.

[RobTrew]

What is the current status of this ?

ghc 7.10.2 here, and a fresh install of stack, but attempted stack installs still fail on OS X 10.11.1 with:

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

Is there any route to a clean install or other fix which would enable stack to work without suspending rootless mode ?

[borsboom]

It looks like you're using ghc-7.8.4. What is your resolver set to?

[RobTrew]

Forgive me, but I have no idea :-) which file do I look at ?

(as far as I am aware there is no copy of 7.8.4 on the system)

stack.yaml shows:

resolver: lts-2.14

[RobTrew]

Thanks !

Your question prompted me to edit
~/.stack/global/stack.yaml
and change the resolver line to:
resolver: lts-3.15

Working now :-)

[lukeg101]

Just to mention I am on OS Sierra and I still get this issue