Can't find .so/.DLL errors

[bergmark]

    [ 1 of 53] Compiling Silk.Db.TrashUpload ( src/Silk/Db/TrashUpload.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Silk/Db/TrashUpload.o )
    <command line>: can't load .so/.DLL for: /Users/adam/silk/repo/.stack-work/install/x86_64-osx/custom-silk-2016-01_1/7.10.3/lib/x86_64-osx-ghc-7.10.3/import-types-0.14-15CTYOPVT9F6i24tJCOJvc/libHSimport-types-0.14-15CTYOPVT9F6i24tJCOJvc-ghc7.10.3.dylib (dlopen(/Users/adam/silk/repo/.stack-work/install/x86_64-osx/custom-silk-2016-01_1/7.10.3/lib/x86_64-osx-ghc-7.10.3/import-types-0.14-15CTYOPVT9F6i24tJCOJvc/libHSimport-types-0.14-15CTYOPVT9F6i24tJCOJvc-ghc7.10.3.dylib, 5): Symbol not found: _imporzuKXg7hHUZZwOO3j091elGpi0_ImportziTypesziGoogleziSheet_zdfFromJSONWorkSheetIdzum2_closure
      Referenced from: /Users/adam/silk/repo/.stack-work/install/x86_64-osx/custom-silk-2016-01_1/7.10.3/lib/x86_64-osx-ghc-7.10.3/import-types-0.14-15CTYOPVT9F6i24tJCOJvc/libHSimport-types-0.14-15CTYOPVT9F6i24tJCOJvc-ghc7.10.3.dylib
      Expected in: flat namespace
     in /Users/adam/silk/repo/.stack-work/install/x86_64-osx/custom-silk-2016-01_1/7.10.3/lib/x86_64-osx-ghc-7.10.3/import-types-0.14-15CTYOPVT9F6i24tJCOJvc/libHSimport-types-0.14-15CTYOPVT9F6i24tJCOJvc-ghc7.10.3.dylib)

After switching to stack 1.0.2 I have gotten these errors on four different occasions. This seems to act similarly to #1498; Once the error occurs it can be reproduced by calling stack build again, but after a clean the error might show up elsewhere for a different package, or not at all.

I realize that this may not be enough information to fix the problem since I can't reliably reproduce it, but perhaps someone else runs across this and can provide a reproduction or bisect to the offending commit. Or perhaps someone knows what changes might have caused this? I'd be happy to try runnning an intermediate stack build for a while to see if this shows up again.

[mgsloan]

Hmm, this is really curious, I'm not sure what would cause it. Are you fairly sure that it's the stack version that caused this change, rather say, the ghc or Cabal version? I realize it's hard to be sure with something like this that only happens occasionally. I'm having a hard time imagining how this error could be anything but an upstream issue, so labeling it as such though it might not be.

[bergmark]

I'm sure the ghc version hasn't changed at least. I also haven't seen this problem in the two weeks since I reverted to stack 1.0.0.

[bergmark]

I've upgraded to stack 1.0.4 and have yet to encounter this again, I'll give it a few days and close this issue if it doesn't show up again.

[bergmark]

This hasn't happened since so I'll close this.