-
Notifications
You must be signed in to change notification settings - Fork 82
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
Alex generates code that cannot be compiled by GHC 9.2 #246
Comments
Quick question @Vekhir, out of curiousity : Is there any reason why you are using 0.23.7 and not the latest release, 0.23.8 of |
@andreasabel There are three main reasons:
In short, there is nothing to suggest that 0.23.8 fixes this issue, so I stick with the version that the official Arch package uses. |
Thanks for the answer! I checked building 0.23.7 with GHC 9.2.8 and everything went fine:
Could it be that you have some But now I see that you might be using the
Try using |
The package is built in a clean chroot, i.e. in a newly created, isolated environment and according to the instructions in the PKGBUILD. This means that not Output of |
It could well be that this I suppose I have no experience with |
I don't think this is a problem of |
I've collected some more information which might be useful.
Interesting resultInterestingly enough, the former "hot" version does contain the What do you think? InfoRunning with
Of note is the line
which only occurs once and is seemingly only run for
which is repeated several times, but always the same. I've also extracted the For completeness, here is the hopenpgp-tools.cabal for 0.23.7, as available on Hackage. runhaskell Setup
|
I see that
This may prevent their (re-)generation with Apparently, their tarball was not created with |
In fact, I checked the tarball of 0.23.8, and it no longer includes the generated @Vekhir : Could you report the progress to https://salsa.debian.org/clint/hopenpgp-tools/-/issues/6 ? I don't have an account there and cannot log in with my github account there. |
Adding a step to first delete the
One takeaway for me is to always check out the updates to get the differential, even if it introduces new variables. Though I will take the fix over updating in this case, for now at least.
Done! Thanks for your help in investigating the issue. Can you close this issue as completed (vs. not planned)? |
@Vekhir: I am happy that I could help you solve this issue! I suppose "closing as not planned" does include the case that the issue was never on our side ( Would you please reopen https://salsa.debian.org/clint/hopenpgp-tools/-/issues/6 ? |
What are the reasons for that? There were no issues with |
The problem is that the wrong packaging is a mine that people may randomly step on (like it happened for you). |
Hi,
the issue occurs with the package
hopenpgp-tools
(Hackage, source).The code works fine with GHC 9.0.2, but fails to build with GHC 9.2.8 with the errors below. They concern some changes with
IntN#
requirements in the type signatures. It looks similar to #187, but occurs on bothalex
3.2.7.4 and 3.4.0.0 as released on Hackage.I also made a report over at
hopenpgp-tools
: clint/hopenpgp-tools#6Edit: Solution
Older versions of
alex
generate code incompatible with GHC 9.2, which is fixed in newer versions. However, packaging issues can preventalex
from regenerating code from incompatible versions. Make sure that the package does not include build artifacts.System information
OS: Arch Linux
Kernel: Linux 6.5.7-arch1-1
GHC: 9.2.8
hopenpgp: 2.9.8
hopenpgp-tools: 0.23.7
alex: 3.2.7.4, 3.4.0.0
Error log:
The text was updated successfully, but these errors were encountered: