Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
'cabal install' fails with fresh install of 2014.2.0.0 for Windows, 64bit #139
Running the installer for 2014.2.0.0 and accepting all defaults on a Windows Vista Enterprise SP2 (work machine, not my fault) machine, then 'cabal update', then 'cabal install cabal-install' results in:
Also, uninstalling 64bit and similarly installing 32bit 2014.2.0.0 does not exhibit this problem.
Thanks for the report. If you do not mind, I would like to ask some questions and share some suggestions that might give some more info.
One thing that might be useful to try for more info is to use the --verbose option for cabal (or -v) and set it to the highest setting (e.g., -v3). True to the name, it is quite verbose, so redirecting the output to a file is recommended.
I just tried what sounds like the same steps you describe and I had no problem (on x64). However, doing those steps did suggest to me some potential things to examine.
When I did this experiment just now, I brought up a new cmd instance, checked the PATH to make sure it was as expected. I wonder if there is a possible problem with "cabal install cabal-install" on Windows under the following scenario: the cabal.exe which gets newly installed in fact is being installed over top of the currently-running cabal.exe (i.e., same location)?
This could cause a problem with overwriting the existing, presumably open file cabal.exe. In the above situation, this scenario might occur if in fact the cmd instance was created before the HP install and thus had an unmodified PATH (i.e., no directories from the newly installed HP 2014.2.0.0). That is, the PATH update is not reflected in any existing cmd instances but will be evident in any cmd.exe launched after the install. Then, if the use of an older cmd instance is possible, there might also have been an older cabal.exe in the user's cabal directory (i.e., %APPDATA%\cabal\bin\cabal.exe), which is where "cabal install" by default (and with --user) will put packages and binaries.
You may also want to examine whether the cabal config file might be defaulting to putting installs into the global location rather than the user location. The config is %APPDATA%\cabal\config. Doing that could cause some permissions problems.
The "does not exist" message might actually be interpreted as "setup-Cabal-....exe reports the following: something does not exist but we aren't telling you what it is that does not exist" For this particular part of the problem, the -v3 verbosity would very likely reveal more around the time of the error.
edit: Also, note issue #51 which notes that updating cabal.exe should be done with --global, otherwise the PATH settings will not allow the newly installed (in the user area) cabal.exe to be used.
Thanks for the response randen. I'll run with '-v3' in a cmd window first
edit: Almost there. I had a C:\Mingw\bin early in the path. Removing it and running,
If I uninstall / re-install HP and do not upgrade cabal-install, other package installs proceed normally.
On Wed, Aug 13, 2014 at 5:33 PM, randen firstname.lastname@example.org wrote:
referenced this issue
Aug 18, 2014
HP 2014.2.0.0 installs Cabal 1.20 . . .
Running 'ghc-pkg check -v' however seems to show an incomplete install . . .
Resolved. The last comment trigger the thought, "Why -is- hlint showing errors?" It shouldn't be installed at all. I've uninstalled and re-installed HP then ran 'ghc-pkg check'. So, I uninstalled HP for the eleventy-third time and this time deleted %APPDATA%\cabal and %PROGRAMFILES%\ghc. Re-installed HP,
Cleaning up the additional directories seems to have resolved my issues.
Perhaps the uninstaller could be made to check for these dirs and remove them - or prompt the user to?
Thanks 23Skidoo and randen for your help and patience.
While researching this issue this page kept coming up for me so I'll document my solution for future searchers. I had another gcc in the path (\Programming\IDEs\GnatStudio\bin;) that it was hitting. I guess it was the wrong kind of gcc and something was failing. I removed that from the environment path and everything started working.
To find the issue I had to use - v3 as mentioned above but also, unless I overlooked something, had to clear my tempdata. Then the message was more clear.
CThuleHansen, there seem to be a couple of problems tangled in this one issue, so it is not clear to me which problem here you might be having. Could you review the various problems above and see which one it is that you are having, and possibly try some of the noted work-arounds mentioned in this issue, or please submit a new issue if you are having a problem that sounds like the title of this issue but has different details.