Unusual strange errors after recent stack updates #2047
Comments
|
Thanks, I'm not sure what's up with that. All the issues are happening with programs invoked by Cabal. Is it possible that you also updated your snapshot version around when updating your stack version? Not sure what we could pass to So, other than this being associated with a stack update, this is seeming like an upstream issue - marking as such. Does it go away if you downgrade to the version you were using? |
|
I have a feeling that the underlying problem is maybe related to #1957 non stack managed compilers and global pkgs installed can lead to this kind of behavior and maybe there is a way for stack to handle it better Can you try to reproduce this using a compiler managed by stack? |
As I remember, I was using LTS-5.12 from the bery beginning.
I have downgraded both cabal-install and stack packages to the versions of the middle of March. Unfortunatelly, today I had some errors too. Example of a new error (not present on screenshots): And gcc error: |
I have a |
|
Here are a bit more details on error happening while building lens. This is a more detailed info I get with Here we see that Even ater removing Btw, it happens for the second project for which I use LTS 5.8. The only way to fix it is to remove While I was writting this message I thought that I know why it happens and then I tried to reproduce it on my machine using the following steps:
But magically project B was built successfully, so once again I have no idea what's going on and what can I do. :( And I can't reproduce it now, but chances are something similar will happen again later. |
|
@gromakovsky Thanks for all the info. I have no idea what's going on there :/ It'd be helpful to create a dockerfile (and ideally, an uploaded docker image) which reproduces the issue. |
@gromakovsky hmm interesting, Stack seems to be ignoring the config(?) under some cases since both failing logs show |
I stil don't know a stable way to reproduce these errors on my machine. Sometimes some ideas come into my mind, I try them, but suddenly there is no error. Then I think: well, errors magically disappeared, everything is fine now, I can be happy. But after some time I get such errors again and this story happens again :( @luigy
is expectable. I can try building project B with stack's GHC, but as I said, this problem doesn't happen anymore. Maybe it would be better to create two issues for these two types of errors, but when I created this issue I was sure they are related to each other. |
|
I'm experiencing this after changing the snapshot for my project from lts-5.3 to lts-5.2. I've wiped the Here's the build log: |
|
@runeksvendsen in this case it doesn't seem to be using a non-stack managed compiler directly, but it could be that the snapshot-db registered packages are still pointing at outdated package-ids It's been a bit since the last time I took a look at this, but I vaguely recall that this might happen when manually nuking files within Usually the second should happen with non-stack managed compilers, since probably a package manager is usually messing with flags + global db which may render different installed package IDs leaving the precompiled cache with outdated information Can you lpaste the output from: WARN: I was also wondering how unsafe would it be to simply run and wether it fixes anything 🙈 @mgsloan the above might help, but it still means that the precompiled cache is still carrying outdated information, right? or actually it might get updated correctly after a successful either way when in doubt the answer is always nuke ~/.stack... maybe |
I think we should definitely avoid that. I really don't want people to feel like they need to nuke it all the time. I haven't needed to in months, so it sucks to see people hitting issues like this.
True, but I don't think that's much of a problem. I moved a comment around while looking into this - the code here checks if the precompiled cache refers to something that exists 0bc1946 |
|
@luigy Here is the requested info: http://lpaste.net/163098 For some reason I expected nuking the project's Is there a bona fide way of changing the resolver for a project? Or is nuking
Let me know if you want me to run that. As long as it only affects |
It shouldn't be necessary to nuke Simply changing stack.yaml should be enough to have the effect you want on build results. It is tricky to get this 100% correct, though, particularly when we do not control the build process (delegated to Cabal) |
|
He-he, now I get even more strange errors: |
|
Are all of your modules listed in your cabal file? |
|
Yes, they are. In fact this error (internal error in ld) happens very rarely and it's enough to rerun Maybe the reason is that archlinux's version of ld has bug… |
|
Closing this issue due to lack of repro and potential |
First of all, I want to notice that I feel a bit awkward writting it, because I have no idea how to reproduce these errors and maybe they are not reproducible on other machines at all. Anyway, after such errors started happenning too often and for more than project I decided that I shouldn't silently ignore them and rebuild, but open an issue.
I use stack version 1.0.4.3-5 from official Archlinux package (
community/stack). I have been using it for a long time and everything was fine. However, after I started writing a new project some strange errors started to occur. It's worth mentioning that before it there were multiple updates ofcommunity/stackpackage. For the first time I didn't care much about these errors,stack clean && stack buildusually was enough (though sometimes build failed even after clean). Then I started testing my code, so I needed to rebuild it frequently and I got too much errors so that I even made screenshots to share with my colleagues. Here they are:There were other errors too, I can collect more if needed, but I guess these 4 are enough to see that something is broken. Unfortunately, I don't have printed versions, because I didn't plan to open an issue at that time.
Today I switched to work on another project, I never had any difficulties building it. Before it I removed
~/.stackdirectory, sostack buildhad to download wholelts-5.8snapshot used in that project. Runningstack build rscoinresulted into this error:Then I tried to rebuild it, but error didn't disappear. Then I tried
lts-5.12and got another error:However, running
stack clean; stack buildeliminated this error.Here is a gist containing two logs (building with 5.8 and 5.12): https://gist.github.com/gromakovsky/4f38f05c44e3a525f9d2c3fa1a0d0b97
In coclusion I want to apologise for not providing ways to reproduce any of these errors. First of all, I don't know how to reproduce it on my machine (as I said, these errors happen non-deterministically) and don't have enough time to research it, trying to find a deterministically reproducible example. Also I have a feeling that such problems may be related to Archlinux, or maybe even my particular machine, so I'm not sure if it will be possible to reproduce them somewhere else.
The text was updated successfully, but these errors were encountered: