Skip to content
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

stack master fails to build; reporting a shadowed dependency error #4107

Closed
parsonsmatt opened this issue Jun 21, 2018 · 16 comments
Closed

stack master fails to build; reporting a shadowed dependency error #4107

parsonsmatt opened this issue Jun 21, 2018 · 16 comments
Projects
Milestone

Comments

@parsonsmatt
Copy link
Contributor

General summary/comments (optional)

stack master fails to build the cardano-sl repository on the develop branch right now (commit b7a3334e48f660387fa98202ce413a7cad8c3d57 as of this writing). stack-1.7.1 works fine.

Steps to reproduce

For example:

$ git clone git@github.com:input-output-hk/cardano-sl
$ cd cardano-sl
$ stack upgrade --git
$ stack build

Expected

ExitSuccess

Actual

$ stack --version
Version 1.8.0, Git revision d9952087654f7bbdfe1ee165c6d137733edcda11 x86_64 hpack-0.28.2
$ stack build
... snip ...
--  While building custom Setup.hs for package cardano-sl-block-1.3.0 using:
      /home/matt/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-2.0.1.0 build lib:cardano-sl-block --ghc-options " -ddump-hi -ddump-to-f
ile -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/matt/Projects/cardano-sl/.stack-work/logs/cardano-sl-block-1.3.0.log

    Configuring cardano-sl-block-1.3.0...
    Preprocessing library for cardano-sl-block-1.3.0..
    Building library for cardano-sl-block-1.3.0..
    <command line>: cannot satisfy -package-id pipes-4.3.9-D0KIqlrhn0v8vLVzrSzVkI:
        pipes-4.3.9-D0KIqlrhn0v8vLVzrSzVkI is unusable due to shadowed dependencies:
          mmorph-1.1.2-KKZMr2x9eQv4KwETGEYeu
        (use -v for more information)
$ stack-1.7 --version
Version 1.7.1, Git revision 681c800873816c022739ca7ed14755e85a579565 (5807 commits) x86_64 hpack-0.28.2
$ stack-1.7 build
... successful build

gist with verbose output

Stack version

$ stack --version
Version 1.8.0, Git revision d9952087654f7bbdfe1ee165c6d137733edcda11 x86_64 hpack-0.28.2

Method of installation

Problem version via stack upgrade --git

@dbaynard
Copy link
Contributor

That's not good. I've just closed an issue though (#4084), and that branch of cardano-sl (on ghc-8.2.2, though) does build with dbc74ec, which is 10 commits behind d995208 (including merges). It may be quite straightforward to bisect, especially if that works. Would you be able to test the latter commit?

The issue there was due to conflicts in .stack-work, so a stack clean --full may help too, if you haven't already tried that.

If those suggestions don't help, or if the issue is due to a recent commit, I'll find somebody to take a closer look.

@dbaynard
Copy link
Contributor

Ah, I forgot to say: there's a bug in ghc 8.2.1 as described in haskell/cabal#4959 which may be present in 8.0.1 too (I haven't checked whether it was a regression). This might be relevant.

@parsonsmatt
Copy link
Contributor Author

We're on GHC 8.2.2 for this:

λ ~/Projects/cardano-sl/ develop stack exec -- ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.2

And the exact commit I'm on with the problem:

λ ~/Projects/cardano-sl/ develop git rev-parse HEAD
b7a3334e48f660387fa98202ce413a7cad8c3d57

I'll do a bisect and see what I can find.

@parsonsmatt
Copy link
Contributor Author

so,

$ stack clean --full && stack build
... snip ...
Progress 152/162

--  While building custom Setup.hs for package cardano-sl-block-1.3.0 using:
      /home/matt/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-2.0.1.0 build lib:cardano-sl-block --ghc-options " -ddump-hi -ddump-to-f
ile -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/matt/Projects/cardano-sl/.stack-work/logs/cardano-sl-block-1.3.0.log

    Configuring cardano-sl-block-1.3.0...
    Preprocessing library for cardano-sl-block-1.3.0..
    Building library for cardano-sl-block-1.3.0..
    <command line>: cannot satisfy -package-id pipes-4.3.9-D0KIqlrhn0v8vLVzrSzVkI:
        pipes-4.3.9-D0KIqlrhn0v8vLVzrSzVkI is unusable due to shadowed dependencies:
          mmorph-1.1.2-KKZMr2x9eQv4KwETGEYeu
        (use -v for more information)
$ stack --version
Version 1.8.0, Git revision dbc74ecce2e31b47626d87a1cf3ea6129fed1e99 (5894 commits) x86_64 hpack-0.28.2

So both the current HEAD and the older commit you gave fail to build :\

@dbaynard
Copy link
Contributor

dbaynard commented Jun 22, 2018

That's frustrating.

After some digging, #3554 seems relevant — it and the linked issues refer to GHC ticket 14381 which is a bug in 8.2.2 (fixed in 8.4.4). There should be a workaround in stack, however, and it isn't obvious from that why 1.7.1 works but master does not.

One option (which appeared to improve cache behaviour in a similar sounding issue) may be to remove the extra-deps and use a custom resolver — that has been suggested for cardano-sl in the recent past.

Meanwhile, @snoyberg and @mgsloan seem to have been the most involved with the shadowed dependency/abi errors, so I'll ask them to take a look.

@nh2
Copy link
Collaborator

nh2 commented Jun 22, 2018

I haven't managed to reproduce it yet with clean dirs:

% nice -n19 /home/niklas/src/haskell/stack/.stack-work/install/x86_64-linux/lts-11.6/8.2.2/bin/stack --work-dir cardano-temp-stack-work-1.8 --stack-root $HOME/path/to/cardano-temp-stack-root-1.8 build
...
cardano-sl-wallet-new-1.3.0: copy/register                           
Completed 351 action(s).                     
Log files have been written to: /home/niklas/fpco/iohk/cardano-sl/cardano-temp-stack-work-1.8/logs/
nice -n19  --work-dir cardano-temp-stack-work-1.8 --stack-root  build  4395.25s user 195.04s system 202% cpu 37:41.33 total

~/fpco/iohk/cardano-sl (git)-[remotes/origin/develop] % git rev-parse HEAD
b7a3334e48f660387fa98202ce413a7cad8c3d57

~/fpco/iohk/cardano-sl (git)-[remotes/origin/develop] % /home/niklas/src/haskell/stack/.stack-work/install/x86_64-linux/lts-11.6/8.2.2/bin/stack --version
Version 1.8.0, Git revision d9952087654f7bbdfe1ee165c6d137733edcda11 (dirty) (5937 commits) x86_64 hpack-0.28.2

Could you try it with a clean --work-dir and --stack-root, like I did here?

(No need to delete your existing stack root, just passing these two flags with two nonexistent directories; but you do have to stack clean --full in order to remove the .stack-work dirs of subdirectories.)

@parsonsmatt
Copy link
Contributor Author

I did the commands you asked and it built fine. I cleared my ~/.stack out and everything's working.

Not sure how it got into this state 🤔

@dbaynard
Copy link
Contributor

@parsonsmatt that's good to hear.

This should be resolved with documentation of the fix used by @nh2 above; apparently similar issues (shadowed dependencies) have cropped up in IRC.

@parsonsmatt
Copy link
Contributor Author

I think it would be better if the issue were resolved by identifying how and why the stack-root directory is getting borked and fixing that. Having rm -rf be part of my regular workflow is part of why I moved from cabal-install in the first place.

@snoyberg
Copy link
Contributor

I agree on that front. Without a reliable repro, though, it will be all but impossible to confirm that this is fixed. My best bet for improving this situation is #3922, which is a systematic improvement on how a number of the pieces of Stack related to this behave.

@parsonsmatt
Copy link
Contributor Author

parsonsmatt commented Jul 7, 2018

I'm having another instance of this occurring. This time, trying to do:

$ cd
$ stack install importify --resolver lts-10
...
--  While building custom Setup.hs for package turtle-1.4.6 using:
      /home/matt/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-2.0.1.0 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/matt/.stack/global-project/.stack-work/logs/turtle-1.4.6.log

    Configuring turtle-1.4.6...
    Preprocessing library for turtle-1.4.6..
    Building library for turtle-1.4.6..
    <command line>: cannot satisfy -package-id async-2.1.1.1-K429Y4XjamzDpSomhW85Gx: 
        async-2.1.1.1-K429Y4XjamzDpSomhW85Gx is unusable due to shadowed dependencies:
          stm-2.4.5.0-15FdumhhnVEKazIoQZDzp1
        (use -v for more information)

Doing an rm -rf .stack/snapshots/x86_64-linux/lts-10.10 doesn't help.

Attempting a stack install importify --resolver lts-10 --stack-root ~/.temp-stack now, which succeeds.

@snoyberg
Copy link
Contributor

snoyberg commented Jul 9, 2018

Good to have a reproducible case for this @parsonsmatt. Just to confirm, can you tell me:

  • Are you running this from outside of a project? I'm guessing that's what the cd command meant
  • Do you have any global settings in ~/.stack/config.yaml or elsewhere?
  • Your command says lts-10, which implies it will be using the latest lts-10. That version is in fact lts-10.10 right now, but can you confirm that explicitly using --resolver lts-10.10 does the same thing?
  • I'm guessing there's something in the precompiled cache leaking in and breaking stuff if the rm -rf fails. Can you dump the full output from another run into a Gist or paste?
  • After the stack build command fails, could you run then following commands?
stack --resolver lts-10.10 exec -- ghc-pkg list
stack --resolver lts-10.10 exec -- ghc-pkg check
stack --resolver lts-10.10 exec -- ghc-pkg describe turtle
stack --resolver lts-10.10 exec -- ghc-pkg describe async

@snoyberg snoyberg added this to To do in Pantry Aug 7, 2018
@snoyberg snoyberg moved this from To do to Backlog in Pantry Aug 7, 2018
@philderbeast
Copy link
Contributor

I did a version bump on LTS for ghc-8.2.2 and saw a similar shadowed dependencies error for the statistics package;

> stack build statistics --resolver=lts-11.21
> stack build statistics --resolver=lts-11.22
statistics-0.14.0.2: configure
statistics-0.14.0.2: build

--  While building package statistics-0.14.0.2 using:
      /Users/pdejoux/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.0.1.0 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: /Users/pdejoux/.stack/global-project/.stack-work/logs/statistics-0.14.0.2.log

    Configuring statistics-0.14.0.2...
    clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
    Preprocessing library for statistics-0.14.0.2..
    Building library for statistics-0.14.0.2..
    <command line>: cannot satisfy -package-id monad-par-0.3.4.8-7qOnwPjydg24v0NeT8UT7f:
        monad-par-0.3.4.8-7qOnwPjydg24v0NeT8UT7f is unusable due to shadowed dependencies:
          parallel-3.2.2.0-JRL2s8v20l0CCDEHFmV4Me
        (use -v for more information)

Deleting the following, I'm now able to build statistics on both lts-11.21 and lts-11.22;

/Users/pdejoux/.stack/snapshots/x86_64-osx/lts-11.21/
/Users/pdejoux/.stack/snapshots/x86_64-osx/lts-11.22/
> stack --version
Version 1.9.1, Git revision f9d0042c141660e1d38f797e1d426be4a99b2a3c (6168 commits) x86_64 hpack-0.31.0

@dbaynard
Copy link
Contributor

dbaynard commented Nov 7, 2018

Thank you, @philderbeast.

That clang warning has a fix, by the way (see #4009).

@qrilka
Copy link
Contributor

qrilka commented Mar 11, 2019

@snoyberg as #3922 was resolved are we OK with closing this issue? Or maybe we need some integration test?

@snoyberg
Copy link
Contributor

Yeah, I think we can close until we have another occurrence of this.

Pantry automation moved this from Backlog to Done Mar 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Pantry
  
Done
Development

No branches or pull requests

7 participants