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