Cabal build targets erroneously depend on package library #7311
Comments
|
Could you share a small example package that reproduces this? PCG looks pretty big |
|
@fgaz you are correct that PCG is pretty big, but I'm unaware of what to prune while still replicating the issue. |
|
@fgaz for a little more context here, building Where |
|
@fgaz I pruned about 2000 lines from the cabal file, including the To Reproduce |
|
I still have to test this properly, but my guess is that the bug has been there even before |
|
@fgaz I can attest that this behavior has been occurring for over a year with |
|
Can reproduce, though I had to add When building And I also get the warning But the So to me it looks like this is a spurious warning from ghc, or the warning message cuts off a part of the id |
|
@fgaz Would you recommend opening an GitLab issue on the GHC issue tracker and reference this GitHub issue? |
|
There are a couple at least related GHC issues opened already, e.g., https://gitlab.haskell.org/ghc/ghc/-/issues/19518 I've mentioned this issue there. Let's see what comes up from the investigation on the GHC side. |
@recursion-ninja: are you sure the CI failures were with cabal 3.2? Did you perhaps see any with cabal 3.4? We suspect, in #5782 (comment), that the bug of depending on older build of an internal library was fixed in cabal 3.2, so your report is worrisome. |
|
Correction: I think only cabal 3.4 fixes the wrong cached compilation of internal libraries bug for good (not only prevents a build failure, but ensures old libraries are not being linked in). @recursion-ninja: if you find any build failure or wrong compilation results with cabal 3.4, please kindly report. This is most probably unrelated to the GHC bug and much more serious (but, I hope, fixed). |
|
@Mikolaj There were some stochastic failures in |
|
@recursion-ninja: thank you for the details, it matches our latest experiments (3.2 can cause a build failure, rarely, when the old compiled version of the library erroneously linked in has different types than the new one; also, it leads to wrong results even more easily if the types agree, but values don't). Nevertheless, let's keep the issue open until the GHC bug is fixed that causes the wrong warnings. |
|
I may have spoken too soon regarding the stochastic build failures. I have recently been having trouble reliably building Steps to reproduce (stochastically): |
|
Minus six, you say? At least that looks different than the failures from #5782, so I'm not reopening that (yet). Will try to reproduce and look at -v2, etc. |
|
Can't repro with cabal 3.5 from master branch. Which cabal is this? Can you reproduce with freshly built cabal? |
|
@Mikolaj I can try rebuilding with a freshly built version of |
|
Great. Yes, master branch is fine. And yes, building |
|
Same Here is a Gist transcript of the |
|
I've repeated the build, with newest cabal and again, I can't find any "Failure" or "Error" when running with https://gist.github.com/Mikolaj/4ab6deaf65c0906df6163592bf50a5ce |
|
@Mikolaj Is there some way I could attempt to debug a potential problem with in my cabal store or |
|
@recursion-ninja: running with an external store, as in my example command ( |
|
The erroneous "were not needed for compilation" warning from the start of this ticket is most probably fixed in GHC HEAD in https://gitlab.haskell.org/ghc/ghc/-/commit/aef7d51350feebfb29a011361d03b249049a2a0b |
Describe the bug
Cabal appears to be requiring an internal package erroneously.
The following warning is reported repeatedly for many build targets:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No build target should depend on
phylogenetic-component-graphas a dependency, however many build targets do tacitly depend on this package despite it not being specified in thebuild-dependsstanza.System information
cabal-3.2,cabal-3.4ghc-8.8.4,ghc-8.10.4,ghc-9.0.1Additional context
I think that there is some erroneous behavior with the sub-library feature.
The text was updated successfully, but these errors were encountered: