GHCI fails to run for ghc@8.6.5

  • Done
  • quality assurance status badge
Details
2 participants
  • Jacob MacDonald
  • Timothy Sample
Owner
unassigned
Submitted by
Jacob MacDonald
Severity
normal

Debbugs page

Jacob MacDonald wrote 6 years ago
(address . bug-guix@gnu.org)
CACy6W0D6g+qYWgMzjW5p_rp9tpm0+5TRMiU60vBDQ=LFZQW+vg@mail.gmail.com
To reproduce, just guix environment --ad-hoc ghc -- ghci. ghc@8.4.3
works. Seems like this may be related to some Prelude changes upstream
familiar enough with GHC internals to really tell what's going on.
Interestingly, when I try to run plain old GHC on some source files
with 8.6.5 I get another seemingly unrelated error:

Bad interface file:
/gnu/store/8v1sn5ns7r5n02aip0b0ypyyzb2y1i1a-ghc-8.4.3/lib/ghc-8.4.3/base-4.11.1.0/Prelude.hi
mismatched interface file versions (wanted "8065", got "8043")
|
1 | import Test.Hspec (Spec, it, shouldBe)
| ^

Again, I'm afraid I'm not entirely familiar with GHC internals and the
function of interfaces files. Nevertheless, it seems not all is well
in Guix-Haskell-land.
Timothy Sample wrote 6 years ago
(name . Jacob MacDonald)(address . jaccarmac@gmail.com)(address . 37361@debbugs.gnu.org)
87blvsx5ps.fsf@ngyro.com
Hi Jacob,

Jacob MacDonald <jaccarmac@gmail.com> writes:

Toggle quote (14 lines)
> To reproduce, just guix environment --ad-hoc ghc -- ghci. ghc@8.4.3
> works. Seems like this may be related to some Prelude changes upstream
> (https://gitlab.haskell.org/ghc/ghc/issues/16563), but I'm not
> familiar enough with GHC internals to really tell what's going on.
> Interestingly, when I try to run plain old GHC on some source files
> with 8.6.5 I get another seemingly unrelated error:
>
> Bad interface file:
> /gnu/store/8v1sn5ns7r5n02aip0b0ypyyzb2y1i1a-ghc-8.4.3/lib/ghc-8.4.3/base-4.11.1.0/Prelude.hi
> mismatched interface file versions (wanted "8065", got "8043")
> |
> 1 | import Test.Hspec (Spec, it, shouldBe)
> | ^

I believe this should be fixed by 83aa656217. I made a mistake when
refactoring the GHC 8.6 package definition, and it was not setting its
search paths correctly.

Can you try again and confirm that it’s fixed?

Thanks!


-- Tim
Jacob MacDonald wrote 6 years ago
(name . Timothy Sample)(address . samplet@ngyro.com)(address . 37361@debbugs.gnu.org)
CACy6W0D1Tt2OVdf5Pv0LeD3X84tWbyEBFr=bG=cpCX-K+G769A@mail.gmail.com
Toggle quote (2 lines)
> I believe this should be fixed by 83aa656217.

That does indeed fix both bugs. In my specific case I'm still running
into an issue with dependency shadowing, but it seems like a separate
issue and I'll open a new one if it's not on my side.

Thanks.
Timothy Sample wrote 6 years ago
(name . Jacob MacDonald)(address . jaccarmac@gmail.com)(address . 37361-done@debbugs.gnu.org)
874l1kwxvc.fsf@ngyro.com
Hi Jacob,

Jacob MacDonald <jaccarmac@gmail.com> writes:

Toggle quote (8 lines)
>> I believe this should be fixed by 83aa656217.
>
> That does indeed fix both bugs. In my specific case I'm still running
> into an issue with dependency shadowing, but it seems like a separate
> issue and I'll open a new one if it's not on my side.
>
> Thanks.

Thanks for checking so quickly. :)


-- Tim
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 37361@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 37361
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help