New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
notcome opened this Issue Jul 11, 2015 · 29 comments

Comments

Projects
None yet
7 participants
@notcome

notcome commented Jul 11, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 11, 2015

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

This comment has been minimized.

notcome commented Jul 11, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 11, 2015

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

This comment has been minimized.

notcome commented Jul 11, 2015

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

This comment has been minimized.

Contributor

alexbiehl commented Jul 11, 2015

Same with cabal install

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

This comment has been minimized.

notcome commented Jul 11, 2015

/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

This comment has been minimized.

Contributor

alexbiehl commented Jul 11, 2015

@notcome

This comment has been minimized.

notcome commented Jul 11, 2015

@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

This comment has been minimized.

Contributor

alexbiehl commented Jul 11, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 11, 2015

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 borsboom closed this Jul 11, 2015

@borsboom borsboom changed the title from Setup.hs: /usr/bin/ar: permission denied to Setup.hs: /usr/bin/ar: permission denied on OS X 10.11 "El Capitan" Jul 11, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 11, 2015

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.

@borsboom borsboom reopened this Jul 11, 2015

@borsboom borsboom added this to the Later improvements milestone Jul 11, 2015

@notcome

This comment has been minimized.

notcome commented Jul 11, 2015

cabal install parsec works fine on my Mac.

@notcome

This comment has been minimized.

notcome commented Jul 13, 2015

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

This comment has been minimized.

notcome commented Jul 13, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 13, 2015

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

This comment has been minimized.

Contributor

phadej commented Jul 14, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 16, 2015

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

This comment has been minimized.

notcome commented Jul 16, 2015

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

在 2015年7月16日,12:31,Emanuel Borsboom notifications@github.com 写道:

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

This comment has been minimized.

Contributor

phadej commented Jul 16, 2015

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

Example after steps in haskell/cabal#2653 (comment)

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

This comment has been minimized.

Contributor

borsboom commented Jul 21, 2015

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

This comment has been minimized.

Contributor

phadej commented Jul 22, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 22, 2015

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

@borsboom borsboom closed this Jul 22, 2015

@katrielalex

This comment has been minimized.

katrielalex commented Sep 29, 2015

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

This comment has been minimized.

Contributor

borsboom commented Sep 29, 2015

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

This comment has been minimized.

RobTrew commented Nov 23, 2015

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

This comment has been minimized.

Contributor

borsboom commented Nov 23, 2015

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

@RobTrew

This comment has been minimized.

RobTrew commented Nov 23, 2015

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

This comment has been minimized.

RobTrew commented Nov 23, 2015

Thanks !

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

Working now :-)

borsboom added a commit that referenced this issue Nov 26, 2015

borsboom added a commit that referenced this issue Nov 26, 2015

mgsloan added a commit to seahug/pcph that referenced this issue Apr 7, 2016

rcook added a commit to seahug/parconc-examples that referenced this issue Apr 7, 2016

Create Stack configuration and README.md with setup instructions
Includes workaround to stack.yaml config to auto install alex/happy:
commercialhaskell/stack#595 (comment)

Uses lts-5.11 (GHC 7.10) for El Capitan compatibility:
commercialhaskell/stack#563

rcook added a commit to seahug/parconc-examples that referenced this issue Apr 7, 2016

Create Stack configuration and README.md with setup instructions
Includes workaround to stack.yaml config to auto install alex/happy:
commercialhaskell/stack#595 (comment)

Uses lts-5.11 (GHC 7.10) for El Capitan compatibility:
commercialhaskell/stack#563

rcook added a commit to seahug/parconc-examples that referenced this issue Apr 7, 2016

Create Stack configuration and README.md with setup instructions
Includes workaround to stack.yaml config to auto install alex/happy:
commercialhaskell/stack#595 (comment)

Uses lts-5.11 (GHC 7.10) for El Capitan compatibility:
commercialhaskell/stack#563
@lukeg101

This comment has been minimized.

lukeg101 commented Jul 16, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment