Shadowed dependencies during builds with Cabal 2.0 WAS: cabal 2.0 and alex on macos #4728
Comments
That's an interesting failure mode, why would the dependencies be shadowed? /cc @dcoutts |
|
For the info my macOS version is 10.12.6 with xcode 8.3.3. This project builds on travis with osx 10.11 and xcode 7.3 |
|
Can you please post a |
|
Sure if you can explain what a -v3 log is ? |
|
Just run |
|
Thanks, that produced following output piped to file |
|
Hi, I have also similar issue regarding shadow dependencies. I am using Haskell Platform's generic on my Ubuntu guest (using virtualbox) of my Windows 10 machine. the log of build (using -v3) is here : and without v3, i got the following error: the plan.json is here: is this problem relevant to what OP is made here? |
|
This Stack issue may be related: commercialhaskell/stack#2781. |
|
I just saw this reference from the Stack issue (thank you!). I initially heard about this problem from a user report trying to build Yesod. The failure log is: The user reported to me using the newest Haskell Platform for Windows. |
|
@23Skidoo I was able to knock this down to a minimal reproducing case using only Cabal-the-library (neither Stack nor cabal-install), which hopefully will make it easier to debug this: https:/snoyberg/stack-issue-2781 Let me know if you have any questions about that, happy to assist. |
|
@snoyberg Thank you! I'll try to look into that once I'm back from ICFP. |
|
Sounds great! Enjoy ICFP 🍻 |
|
Any objection to updating the title of this issue to mention "shadowed dependencies?" I think it will make it easier for others to find it (and thereby avoid duplicate reports). |
|
@snoyberg Go ahead. |
snoyberg
changed the title
|
@23Skidoo If any help is needed in testing this on macOS just let me know, I am eager to work on pet project that uses cabal 2.0 :) |
|
Here’s another log of running |
|
Stack issue 2781 may be unrelated; please see my comment there on an explanation of why cabal-repro.sh does what it does. If you are using Haskell Platform full Linux binary tarball, please take a look at the output of the following two commands, especially best right after you have a clean fresh install:
I don't have Mac. If you are using Haskell Platform full Mac binary installer, please try the above, it may be exactly the same cause. The Windows version doesn't have this problem. This is only because the abi-depends field doesn't even exist! This may be because strangely the Windows version was probably built by Cabal 1.x which didn't make the abi-depends field. (Oh the whole affair is strange already, why would "inplace" leak out into final products in the first place? I know one way, but it sounds crazy that anyone would do it.) My conclusion is that Haskell Platform full binary Linux (and maybe Mac) comes broken in the first place. Nothing you can do. (Oh, you could go replace all those "inplace"s by the correct hexstrings... Remember to |
|
If both bugs occurred in settings of a full platform install, I can confirm that the full platform builds were doing the wrong thing as discussed in the referenced HP issue and the above comment. New builds will be out shortly, and in the meantime using the core platform is a workaround. |
|
@ezyang Could you please confirm what I think the shadowed dependency error means:?
Any idea what could be the cause for this? |
|
FWIW I've made a tiny patch to GHC to work around this, it merely disables all shadowed dependency checking. So far none of our code has segfaulted and all the tests pass with this new GHC. Obviously this isn't the correct solution though! nixpkgs revision with this fix in: https:/expipiplus1/nixpkgs/tree/ghc-shadow |
|
The mechanics of shadowing are explained in the manual here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-databases In GHC 8.2, we DO check ABI hashes to be consistent with what is recorded in I don't know how the package database got into this state to begin with, however. |
|
So, it looks like the root cause is that Cabal only reads out ABIs from the database once during configure. So if the package database state changes (as it would if you reregister a package), you technically need to reconfigure. You can see this is the case because
I don't have time to write a patch. Hopefully this is enough for someone else. |
I have noticed this problem with |
|
OK, I stand corrected :) |
|
"this does NOT apply for inplace; inplace packages don't have this problem because inplace packages get registered with 'inplace' ABI so you don't have reregister every time you edit something" -- I'm not so sure this is true. It used to be. But now I think that inplace packages have a full abi and also an inplace tag on it? So if something else depends on an =inplace abi, then it still checks that it matches now... I could be a bit wrong here, but its worth exploring. Or perhaps I don't understand your above comment fully? There's a lot going on here... |
|
When we do an inplace registration (this is a registration to the inplace package database in |
|
@cocreature did your error occur on a system with a full linux hp install? |
|
@gbaz No, just a minimal GHC bindist. |
|
I should probably also add that the only way that I found to fix this was nuking |
|
@ezyang thanks for the analysis. Since regardless of upstream Cabal fix we'll want to work around this issue for older Cabals, I've written a workaround for Stack. For the curious: commercialhaskell/stack#3503. And for the record: yes, this appears to be a completely separate issue from the Haskell Platform bug, just with similar symptoms. |
|
I think it might be best to solve this at the source. Here is the proposal I have filed for GHC: https://ghc.haskell.org/trac/ghc/ticket/14381 |
|
Just as an update, there is a patch on Phabricator now that (crudely) addresses this issue inside See #14381 and Phabricator for more info. I'll work on getting this patch cleaned up for upstream as needed, but excited participants can, of course, apply it themselves and try it out. |
|
@thoughtpolice Thanks for the update! I have opened commercialhaskell/stack#3554 to track eventually disabling the workaround. |
thoughtpolice
pushed a commit
to NixOS/nixpkgs
that referenced
this issue
Dec 4, 2017
In an attempt to work around haskell/cabal#4728
juhp
added a commit
to fedora-haskell/ghc
that referenced
this issue
Jan 14, 2018
|
Not sure if this is the same issue, but we're getting this error message with a clean Nix build (so no mutated package database). Any idea what to look into? |
shlevy
added a commit
to shlevy/nixpkgs
that referenced
this issue
Mar 26, 2018
See haskell/cabal#4728 for symptoms, https://phabricator.haskell.org/D4159 for the base of the fix. (cherry picked from commit 59a53aa)
shlevy
added a commit
to shlevy/nixpkgs
that referenced
this issue
Mar 26, 2018
See haskell/cabal#4728 for symptoms, https://phabricator.haskell.org/D4159 for the base of the fix.
This was referenced Mar 26, 2018
|
I run stack 1.6.5 with resolver: nightly-2018-04-03 (installed with stack) and I see the |
|
@andrewufrank If you're able to build your own GHC, please see if https://phabricator.haskell.org/D4159 fixes it for you. |
|
I will try - thank you! |
|
Correct, it has not been merged yet |
|
too bad - it would have been valuable, if this had been communicated. |
|
I believe that this is fixed in 8.4.3+, see https://ghc.haskell.org/trac/ghc/ticket/14381. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am trying to build a project with
cabal new-buildand I haveghc-8.2.1andIt is failing to build alex (among some other packages but this one fails first)
The build log says
I also tried compiling with
-f-parsecflag with no luckThe text was updated successfully, but these errors were encountered: