Bug in stack build: Cannot satisfy -package-id text-1.2.1.3-3718968f98d5614ccdc45c27d4e8b0a1 (version 0.1.4.0)

[michaelochurch]

I've been working through the stack tutorial and when I try to add a dependency to the .cabal file, it breaks stack build. Here's a full repro:

If it helps, I'm running version 0.1.4.0 of stack, version 7.10.2 of ghc, and on OS X. I'm running with the Haskell Platform on this machine, which may be a factor.

$ stack new project1
Downloading template "new-template" to create project "project1" in project1/ ...
Writing default config file to: /Users/michaelchurch/stack-explore/project1/stack.yaml
Basing on cabal files:
- /Users/michaelchurch/stack-explore/project1/project1.cabal

Checking against build plan lts-3.4
Selected resolver: lts-3.4
Wrote project config to: /Users/michaelchurch/stack-explore/project1/stack.yaml
$ cd project1
$ stack setup
stack will use the GHC on your PATH
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
$ stack build
project1-0.1.0.0: configure
Configuring project1-0.1.0.0...
project1-0.1.0.0: build
Preprocessing library project1-0.1.0.0...
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Lib.o )
In-place registering project1-0.1.0.0...
Preprocessing executable 'project1-exe' for project1-0.1.0.0...
[1 of 1] Compiling Main             ( app/Main.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/project1-exe/project1-exe-tmp/Main.o )
Linking .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/project1-exe/project1-exe ...
project1-0.1.0.0: install
Installing library in
/Users/michaelchurch/stack-explore/project1/.stack-work/install/x86_64-osx/lts-3.4/7.10.2/lib/x86_64-osx-ghc-7.10.2/project1-0.1.0.0-4pj6XN4LKwHF16GBAFLNXm
Installing executable(s) in
/Users/michaelchurch/stack-explore/project1/.stack-work/install/x86_64-osx/lts-3.4/7.10.2/bin
Registering project1-0.1.0.0...
$ emacs project1.cabal
(changed Line 19 to:  build-depends:       base >= 4.7 && < 5, text)
$ stack build
project1-0.1.0.0-9ad763f12faba6c6d538588b14148985: unregistering (dependencies changed)
project1-0.1.0.0: configure
Configuring project1-0.1.0.0...
project1-0.1.0.0: build
Preprocessing library project1-0.1.0.0...
<command line>: cannot satisfy -package-id text-1.2.1.3-3718968f98d5614ccdc45c27d4e8b0a1
    (use -v for more information)

--  While building package project1-0.1.0.0 using:
      /Users/michaelchurch/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-osx-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.4.0/ build lib:project1 exe:project1-exe --ghc-options -hpcdir .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/hpc/.hpc/ -ddump-hi -ddump-to-file
    Process exited with code: ExitFailure 1

[mgsloan]

Hmm, that's odd! I can't reproduce this with Version 0.1.4.1, Git revision fee700e .

[michaelochurch]

I found a workaround when some Googling turned up a related bug someone had
struggled with. It's this:

stack --no-system-ghc --install-ghc build

Apparently (from my incomplete comprehension of that other issue report)
it's a problem with the Haskell Platform in its current state? Would you
recommend deleting the Platform and manually installing all of its
components?

On Fri, Sep 11, 2015 at 8:56 PM, Michael Sloan notifications@github.com
wrote:

Hmm, that's odd! I can't reproduce this with Version 0.1.4.1, Git revision
fee700e
fee700e
.

—
Reply to this email directly or view it on GitHub
#980 (comment)
.

[borsboom]

@snoyberg, is there anything we can do to help out users of HP? A warning, perhaps, if certain kinds of issues are detected in the global package database (or even falling back to --no-system-ghc automatically)?

[snoyberg]

I think there may be a bug in stack, because it should be able to work
around HP idiosyncrasies, or at least most of them. It's going to require a
bit more research to figure out exactly why this is happening.

On Sun, Sep 13, 2015, 6:39 AM Emanuel Borsboom notifications@github.com
wrote:

@snoyberg https://github.com/snoyberg, is there anything we can do to
help out users of HP? A warning, perhaps, if certain kinds of issues are
detected in the global package database (or even falling back to
--no-system-ghc automatically)?

—
Reply to this email directly or view it on GitHub
#980 (comment)
.

[snoyberg]

@michaelochurch I would recommend deleting the HP installation. There seem to be a few problems with it, especially on Mac (missing dynamic libraries causing trouble with GHCi). However, for diagnosing any problem here, could you provide the output for the following commands (preferably as a separate Gist or paste)?

ghc --version
which ghc
ghc-pkg list -v
stack exec which ghc
stack exec -- ghc-pkg list -v
stack build -v

[peti]

This looks like https://ghc.haskell.org/trac/ghc/ticket/4012.

[michaelochurch]

@snoyberg Ok. Here it is: the Gist. I hope that this is helpful. Thank you for taking the time to look into this.

[michaelochurch]

I managed to get this to go away by installing [edit: uninstalling] the Haskell Platform. Should I close this? Should this bug be filed to the Haskell Platform project?

[snoyberg]

Wow, there's something very strange going on here. The output indicates that text-1.2.1.3-3718968f98d5614ccdc45c27d4e8b0a1 is definitely registered, and stack is obviously finding it, but then for some reason GHC isn't able to use it. That does look more like a Haskell Platform bug than anything else, but I can't be certain.

It's your call how you want to proceed; since you've got it working (I'm guessing you mean by __un__installing HP?), feel free to close this and just continue using things. If you're interested in debugging further, the next set of commands I'd ask for a Gist of is:

stack clean
stack build -v
ghc-pkg describe --ipid text-1.2.1.3-3718968f98d5614ccdc45c27d4e8b0a1
stack exec -- ghc-pkg describe --ipid text-1.2.1.3-3718968f98d5614ccdc45c27d4e8b0a1

[peti]

@snoyberg, did you see #980 (comment)? This is a well-known bug in ghc. The library IDs generated by the compiler are non-deterministic. When two compilers build packages A and B, both of which depend on text, then you may end up in a situation where text is compiled twice. Now, both compilers link A and B to their respective variant of text -- possibly referring to the library with conflicting library IDs. Thus, if a machine with A's variant of text ever tries to link B (or vice versa), then you'll see that error. (Some empiric data about the frequency which with that bug occurs lives at https://github.com/peti/ghc-library-id-bug.)

[snoyberg]

@peti Even with non-deterministic builds, stack should be able to handle the situation here correctly. It should be able to tell Cabal/GHC to build with a coherent set of dependencies. For some reason, that appears to not be the case. But it also appears to only be happening on Mac OS X (see #992, which seems quite similar to this).

[peti]

It should be able to tell Cabal/GHC to build with a coherent set of dependencies.

What do you mean by "a coherent set of dependencies"? The dependency set is coherent in the sense that all constraints are fulfilled.

[snoyberg]

What seems to be happening is that stack is providing package IDs for foo and bar, where bar depends on a different package ID for foo.

[peti]

What do you mean by "stack is providing package IDs"? Stack has no idea those IDs exist. A library's ID is determined at compile-time by hashing the interface definitions, etc., and this is one level below what a package manager sees. You should let go of the notion that stack is somehow responsible for this error or that it could have done anything to prevent it from happening. It can't. The issue is completely orthogonal.

@michaelochurch should simply erase ~/.stack, ~/.ghc, and all other spots that contain binary packages, and re-compile everything from scratch to make sure that every binary links to exactly those libraries that it has been built with/for. Other than that, dedicate man-power to fixing https://ghc.haskell.org/trac/ghc/ticket/4012, because that bug is a freakin' nightmare for everybody who's trying to distribute Haskell packages, and it doesn't seems like we'll get rid of it any time soon.

[michaelochurch]

@snoyberg I'm satisfied but I'll only close it if that's what you want. I don't think I understand this problem as well as you do, but it doesn't seem to be a problem in Stack.

Would running those commands still provide useful information, given that I've uninstalled the Haskell Platform? I'll do so if it'll be useful.

[snoyberg]

Thanks, but I don't think it's worth it. I'll wait to see if anyone else files a bug after installing HP, and badger them to run all of these commands ;)