MinGHC 7.10.1 failed to bulid data-default-instances-old-locale version 0.0.1

[GongYiLiao]

I tried to build data-default-instances-old-locale version 0.0.1 on Windows. I got the following error message:

~ $ cabal install data-default-instances-old-locale
Resolving dependencies...
Configuring data-default-instances-old-locale-0.0.1...
Building data-default-instances-old-locale-0.0.1...
Failed to install data-default-instances-old-locale-0.0.1
Build log ( C:\Users\gl67\AppData\Roaming\cabal\logs\data-default-instances-old-locale-0.0.1.log ):
Building data-default-instances-old-locale-0.0.1...
Preprocessing library data-default-instances-old-locale-0.0.1...
[1 of 1] Compiling Data.Default.Instances.OldLocale ( Data\Default\Instances\OldLocale.hs, dist\build\Data\Default\Instances\OldLocale.o )
C:\Users\gl67\repos\MinGHC\7.10.1\ghc-7.10.1\mingw\bin\ar.exe: dist\build\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a-11336\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a: No such file or directory
cabal.exe: Error: some packages failed to install:
data-default-instances-old-locale-0.0.1 failed during the building phase. The
exception was:
ExitFailure 1

I can install data-default-instances-old-locale with ghc 7.10.1 on Linux (Debian) and no such error happened, it seems that MinGHC has some restrictions in locating the compiled objects.

[snoyberg]

This is a cabal bug, see: haskell/cabal#2502

[GongYiLiao]

Since this Is Cabal's bug, this issue should be closed.

[snoyberg]

I agree completely. Perhaps we need to put out s message warning windows users to avoid GHC 7.10 until this bug is fixed.

[ndmitchell]

We have to do something - will distributing an old copy of cabal.exe fix it?

[snoyberg]

Unlikely, as usual the new GHC only works with the newest version of cabal, which always brings in a new set of bugs to be dealt with.

[ndmitchell]

Urk. I guess the newest cabal.exe works (since -j1 works) but the Cabal lib with GHC is broken. Do we need a GHC patch release?

[snoyberg]

I'll look into this a bit more over the next hour, I'm pretty familiar with Cabal breakages at this point.

[snoyberg]

In my testing:

• -j1 has no effect
• Installing newest Cabal and cabal-install has no effect
• Unpacking and building from that directory with or without -j1 seems to work
• Using runghc Setup.lhs works, which is unsurprising considering the previous bullet

It seems like we can tell users to try one of two workarounds:

• If they run into the bug, run cabal unpack pkg-ver && cabal install .\pkg-ver
• Just drop down to GHC 7.8.4 until cabal fixes this

I think a blog post with both of those options makes sense, what do you think Neil?

[ndmitchell]

Agreed. I also think Cabal needs better tests.

[snoyberg]

OK, blog post published: https://www.fpcomplete.com/blog/2015/05/psa-ghc-710-cabal-windows

[3noch]

Aha, I abandoned 7.10 a while back because I couldn't get anything many things to build. Now I know why!

[3noch]

I wonder if this is related: https://github.com/kazu-yamamoto/ghc-mod/wiki/InconsistentCabalVersions

[solatis]

This is related to haskell/cabal#2502 , the fix being part of the cabal version released with the repackaged MinGHC 7.10.1 as discussed in #69 . I think this issue can be closed ?

[snoyberg]

Agreed, good call.