Yesterday I followed the installation instructions for haskell-platform on the official haskell website https://www.haskell.org/platform/
Now I tried to use stack, but I only got command not found as output.
In the environment variables an the path variables, there no reference to stack to be found.
Also, in the chocolatey installation location there is no stack.exe.
Where can i find the stack installation included in haskell-platform?
I just got hit by the same thing. My guess is it's a bug, given the packages aren't in the nuspec. I've just raised an issue. At best there is a discrepancy between the package and the documentation.
Related
I have downloaded and installed a Windows native compiled OpenFOAM from here. But when I try to run any of the OF commands (e.g., blockMesh, foamDictionary, ...) in the MSYS2 terminal I get the message:
path/to/folder/v2106/msys64/home/ofuser/OpenFOAM/OpenFOAM-v2106/platforms/win64MingwDPInt32Opt/bin/blockMesh.exe: error while loading shared libraries: libstdc++-6.dll: cannot open shared object file: No such file or directory
and in the cmd terminal, I get the error message:
System Error The code execution cannot proceed because msmpi.dll was not found. Reinstalling the program may fix this problem.
From here, I see that I might have to reinstall OpenFOAM in admin mode, which I don't have on this work machine. so I tried installing MSMPI using pacman -S msmpi as I used to do here. But I get the error message:
error: target not found: msmpi
My goal is to install and use the OpenFOAM software, doesn't matter which release, on this Windows machine without admin privileges. I would appreciate it if you could help me know how can I fix the above problems, or find another way around.
P.S.1. Searching the installation directory, I see that the libstdc++-6.dll file is in the path\to\folder\v2106\msys64\home\ofuser\OpenFOAM\OpenFOAM-v2106\platforms\win64MingwDPInt32Opt\bin. So I wonder I get the first error message. Maybe OF is not compiled properly against the library? Should I try removing the path\to\folder\v2106\msys64\usr\lib\gcc\x86_64-pc-msys\7.4.0\libstdc++.dll.a as suggested here?
P.S.2. I had written this post ages ago about different ways to install OpenFOAM on Windows. Sadly it is still a big effort to get it up and running.
P.S.3. A follow-up on this issue here on the MSYS2 Discord server.
P.S.4. Opened a new issue here on the OpenFOAM repository.
With OpenFOAM-v2112 it is now possible to install without windows admin permissions.
The original problem will still be evident with older OpenFOAM versions since they relied on installing msmpi separately.
Trying to run a shell script in Git Bash. This particular script requires the Rcpp and RcppArmadillo packages. (creating an R package implemented in C++) Because I am on a Windows system I had to install Rtools40. Upon execution of the sh command I get the error:
fatal error - cygheap base mismatch detected - 0x180316408/0x180317408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
What I've tried:
Following the instructions in the error message. However, a search for cygwin1.dll comes up empty. Additionally, I have never installed Cygwin on my machine.
Updating R, Rtools40, and Git for Windows to the latest versions. This was much needed (apparently Windows doesn't update these programs automatically sigh) but it did not resolve the error message.
Turning off ASLR protections in Windows Security settings as described in this post and this post.
Deleting duplicate msys-2.0.dll files from my drive. This ultimately worked. I will post the solution in detail as an answer to this question.
Hope this helps anyone who, like me, has been sifting through the many posts that don't fully answer this question.
So here's how I solved this problem. From what I understand, the error message in Git Bash is outdated and deceptive. It references Cygwin, but Git Bash actually uses MSYS2, not Cygwin. So instead of searching for cygwin1.dll, I needed to search my drive for msys-2.0.dll. This file was present in two locations: Git\usr\bin and rtools40\SOMETHING (I don't remember the exact path, but it was associated with Rtools40). As per the directions in the error message, I deleted the version that was older, which happened to be the one associated with Rtools40. That left only one version of msys-2.0.dll on my drive, and the sh command then executed in Git Bash with no issues.
What I'm still confused about: Why hasn't the error message in Git Bash been updated? What's the difference between Cygwin and MSYS2? I know they both impose the UNIX environment on Windows, but are there advantages or disadvantages to one or the other? In the long run, if I want to execute scripts through the command line, is Git Bash sustainable, or should I just create a Linux partition on my machine?
I came across a post on GitHub that mentioned that if you are running into this issue after getting a "Resource temporarily unavailable" error, then the issue is likely that you are running 32-bit version of Git. Install Git 64 bit, and your issue should go away
I am using JetBrains GoLand and I am trying to debug my go file and I am getting the following error:
decoding dwarf section info at offset 0x0: too short
I tried to find an answer here at StackOverflow but unfortunately, I didn't get any solution.
GoLand ships with a bundled version of Delve. Update to 2018.2.2 and it should work. If you need to do remote debugging, then you need to update your Delve installation on/for the target machine as well (make sure you compile it with Go 1.11).
Edit:
There are two more possible cases where this issue can appear:
the application was compiled with all the debugging flags turned off and the additional debugging information stripped
the application uses the standard library "plugin" package, which is known to cause an issue in the Go compiler. This will be fixed in Go 1.12.
I would like to share my experience here too as it may be helpful for community, I made it works by doing the following:
Update Goland to 18.3
Also, in case if you have Mac, you should run xcode-select --install
In case if you had delv already installed inside GOPATH/bin, remove it and re-install it again by following instructions here
For my Mac the problem is related to the dlv package as installed by Golang plugin.
Install delv and,
check the path of dlv as executed by IntelliJ (in the console).
Go to this directory
($HOME//Library/Application Support/IntelliJIdea2017.3/intellij-go/lib/dlv/mac)
and rename dlv to any other name. Get the right dlv executable by using
which dlv (/usr/local/Cellar/go/1.11.1/libexec/bin/dlv for my computer)
and add a symbolic link
(ln -s /usr/local/Cellar/go/1.11.1/libexec/bin/dlv dlv).
After hours of effort, I was able to find the issue. It was due to Golang Plugin which is deprecated and was not compatible with IntelliJ IDEA 2018.2.2 (Ultimate Edition).
I uninstalled the plugin and reinstall the IntelliJ.
Hope this also helps to above solutions.
I've been trying to install hmatrix on my (64-bit) Windows 10 computer; after searching through and trying many possible solutions (including the instructions under "Windows" and "Alternative Windows Build" given here), I decided to pursue the course of action given on this Reddit thread.
However, when I type in the command
cabal install hmatrix -fopenblas --extra-lib-dir=${c:\msys64\mingw64\bin} --extra-include-dir=${c:\msys64\mingw64\include}
into the MSYS2 shell, the following log is given:
Resolving dependencies...
Configuring hmatrix-0.17.0.2...
Failed to install hmatrix-0.17.0.2
Build log ( C:\Users\Christian\AppData\Roaming\cabal\logs\hmatrix-0.17.0.2.log ):
Configuring hmatrix-0.17.0.2...
cabal.exe: Missing dependency on a foreign library:
* Missing C library: libopenblas
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Leaving directory 'C:\msys64\tmp\cabal-tmp-4244\hmatrix-0.17.0.2'
cabal.exe: Error: some packages failed to install:
hmatrix-0.17.0.2 failed during the configure step. The exception was:
ExitFailure 1
However, when I check the directory c:\msys64\mingw64\bin, I see that libopenblas.dll is right there; I don't know why cabal can't seem to find it.
Any insight into why this is not working or what to do?
UPDATE:
The files libopenblas.dll.a and libopenblas.a are in the directory c:\msys64\mingw64\lib. Is it possible I need to somehow include this directory as well? (If I do, how would I do that?)
I also downloaded the files in Alex Vorobiev's comment below and put them in c:\msys64\mingw64\bin if they are .dlls or c:\msys64\mingw64\lib if they are .libs. The header files were already contained in c:\msys64\include\openblas.
I tried several variations on the command in the original post after making these changes, including switching \bin with \lib and switching \include with \include\openblas, but all of them still give the same error.
I'm a bit suspicious about the
if os(windows)
if flag(openblas)
extra-libraries: libopenblas
in the cabal file, could you unpack it and remove the "lib" part? If that doesn't work please post a log with -v3 output. I've seen quite a few people with troubles installing this package. So could you also open a ticket on the GHC bug tracker if this doesn't work (and CC me "Phyx-")?
Secondly, you never said which version of GHC you're using. 8.0.1 should have far less trouble (and won't need the hack to get it working in GHCi) since the runtime linker has been overhauled and should be much better on Windows. 8.0.2 will likely include the new import libraries support as well.
I have windows Vista 64 bit. I installed the latest Haskell Platform today (which ghc --version says 7.0.4). I installed the latest cygwin.
I ran cabal install plugins, it had minor issues (I didn't specify prefix path as I should have and there was a missing import in Env.hs), so I cabal expand'ed fixed... it installed.
I run a simple example (specifically this one and I get this error:
Main.exe: user error (loadShared: couldn't load `m' because addDLL: could not load DLL)
Any ideas on how to resolve it?
Oh, and the example works fine on Linux (Ubuntu) GHC 7.0.3, so it's either a Windows for 7.0.4 specific issue.
When it's trying to load libraries, when it looks up the dlls for the integer-gmp package for it receives ["m", "wsock32"]. So the error is caused by it trying to load a dll "m", which apparently doesn't exist. I'm guessing this is a bug somewhere.
After bypassing that, I was able to get further. As Stephen Tetley mentioned, there is another bug about getting an HscEnv. Following that rabit trail, I was able to bypass that. Now, I'm at this error:
Main.exe: Plug.dll.a: Not x86 PEi386
Main.exe: user error (Could not load module `Plug.dll.a')
But I'll mark this question as answered since the specific error I mention in the question is because of what appears to be a bug somewhere in ghc or something.