Hit this compiling darcs on a new machine. . . . But it may be more generic to Haskell platform itself. Bottom line, it presents a situation where someone could end up dead-in-the-water with respect to using haskell libraries. I burned a lot of time tracking this down, it may discourage users from the platform.

The problem manifests itself when your Win32 home directory has a long name (or one with a space) and you're compiling haskeline, linking on the 15th step. Basically, ld.exe croaks when fed one of these names rather than an 8.3

I can provide more specific details on the point of failure on request; but it was a pain to track down. Maybe a change to the linker, or some specific project, may get rid of the 8.3 dependency.

A solution that got me out was to enable 8.3 on the volume, and on the user directory.

A fix:
Logging in as a *different* user:

Open a command prompt with Administrator priveleges

fsutil 8dot3name query c:

(tells you the current status - you probably see a 2 - volume-select of the feature)

fsutil 8dot3name set c: 1

(This sets volume c to create 8.3 names - for future files only)

fsutil file setshortname "c:\Users\YouHaveA VeryBigName" YOUHAV~1

(This only works if you're not logged in as 'YouHaveA VeryBigName', otherwise the directory will be in-use). You need this step as even though you've changed the policy on 8.3 naming, this directory was probably made during the prior policy)

dir /-n
(This shows you the 8.3-sensitive names. You see YOUHAV~1 in the list, you got it right)

The user may need to uninstall and reinstall haskell-platform, and wipe all Cabal and GHC directories under AppData/Roaming