-
Notifications
You must be signed in to change notification settings - Fork 846
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
GHC's -package <pkg>
can expose installed package not listed by ghc-pkg list <pkg>
#6661
Comments
Looking at the gist, one thing that is odd is that the unofficial version of Stack 2.15.7 that you are using itself lists EDIT: Actually, that is a red-herring. I see that where a package has a sub-library (for example, |
I tried with both Also just noting here too (as I mentioned in matrix) that I couldn't reproduce in a fresh Fedora container. |
I uploaded the stack-3.1.1 output too for completeness: https://gist.github.com/juhp/e4f92e6df99524da0d7df72afe2470d4 |
Also I also tried in a container first building with lts-22.41 and then lts-22.43, but this also worked fine. |
I am wondering if this GHC bug is relevant: |
Ah yes indeed - I had quite forgotten about that problem 😢 Is there a related stack issue? |
-package <pkg>
can expose installed package not listed by ghc-pkg list <pkg>
@juhp, I have edited this issue to make it Stack's related issue. |
BTW I finally "took the (small) plunge" and tried moving (aka "deleting") So wonder what triggers this on my machine, since it appears not reproducible, or is it just bad luck? Guess I forgot to write down my workaround, just in case anyway one should hit this somehow, in stack.yaml:
|
EDIT (by @mpilgrem): The anomaly described below is likely due to the bug (from Stack's perspective) in GHC versions described at: https://gitlab.haskell.org/ghc/ghc/-/issues/25025
In short:
name
that is in the format that Cabal (the library) uses to 'mung' sub-libraries, some versions of GHC treat thatname
as if it were the name of the Cabal package for the purpose's of GHC's-package
option; and-package <pkg>
option can, in practice, cause an installed package to be exposed that is not one listed byghc-pkg list <pkg>
.Stack, on the other hand, relies on an installed package having a unique name specified by its
name
field and that GHC's-package <pkg>
option will expose only a installed package listed byghc-pkg list <pkg>
.So far noone else has seen this: so likely it is an anomaly only in my system.
General summary/comments
After updating my projects to latest lts-22 (lts >= 22.42), builds using attoparsec started to fail for me.
Steps to reproduce
(Not reproducible so far except on my laptop)
stack --resolver lts-22.43 build aeson
Expected
To build normally.
Actual
See https://gist.github.com/juhp/8cf70c3e00509347ff5e5f4bbfad74c5 for the full --verbose output
Highlighting a few points:
- attoparsec-0.14.4
appears twice (probably once for attoparsec and once for attoparsec-internal?)--dependency=attoparsec=attoparsec-0.14.4-GAKm7J8Gleq2k06HFjeIeY-attoparsec-internal
(attoparsec:attoparsec-internal gets mapped to the same pkgid)Stack version
2.15.7 and 3.1.1
Method of installation
Fedora Linux and local build
Platform
Fedora Linux
Misc
I am using a workaround: adding
os-string-2.0.6
to my project stack.yaml files (the version of os-string in lts < 22.42)The text was updated successfully, but these errors were encountered: