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.
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.
I am getting this error:
Error in invoking target 'client_sharedlib' of makefile '/u01/app/oracle/product/12.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk'.
Looking in the make.log, I see this error:
/usr/bin/ld: cannot find /usr/lib64/libpthread_nonshared.a
Doing: locate libpthread_nonshared, I get this response:
/home/romio/libpthread_nonshared.a
/usr/lib/x86_64-linux-gnu/libpthread_nonshared.a
which I guess means that the relevant lib is already on my computer.
But I don't know how to proceed from here. How do I tell the program to look the place with the library is? I come from Windows, so I'm yet very weak with Linux. I am running on Ubuntu 16.04
And I guess moving the package to the location oracle is searching must be a bad idea, since there might be other programs that use the package in its current location?
You are using an unsupported linux distribution. You are pretty much on your own. I'd suggest to use a supported linux distribution.
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’ve been experiencing a nasty issue with profiling on Windows. But first, the context of setup:
I created a shared sandbox in ~/dev/foo_shared: cabal sandbox init --sandbox=.
I created a sandbox in ~/dev/foo using the shared sandbox above: cabal sandbox init --sandbox=~/dev/foo_shared
I installed all the dependencies with profiling enabled: cabal install --only-dependencies --enable-library-profiling --enable-executable-profiling
I configured the foo package so that it includes profiling RTS: cabal configure --enable-profiling --enable-executable-profiling
I tried to build with cabal build
Everything builds up correctly, but doesn’t link. I then rebuilt with cabal build -v3, and this is the linker part (the most interesting part):
c:/program files/haskell platform/2014.2.0.0/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lHSrts_debug_p
I googled that, and IIRC, it’s because I lack the profiling library for the GHC’s RTS. I never found it for Windows :( Last information, I’m on Windows 10, not sure it helps though.
Problem solved. The issue is due to the fact I’m using -debug on the command line interface to GHC. I’ve been told -debug and -p are not compatible, hence the error.
I just installed LLVM (3.0) successfully, and got the Hackage bindings (3.0.0.0). However when I try to use it, I get the following linker error:
Loading package llvm-base-3.0.0.0 ... can't load .so/.DLL for: (dlopen(lib.dylib, 9): image not found)
There is no name after "for: ", which makes this frustrating, because I don't know what it can't find. I know there isn't much information to go on, but does anyone have any idea why this could be happening?
I am running Mac OS X, in case it matters.
It's a bug in the llvm bindings installer. I had it patched locally and just sent a pull request to bos, hopefully it will get merged soon.
To fix your problem without the patch, find the llvm-base package config file. Mine is located here:
~/.ghc/x86_64-darwin-7.4.1/package.conf.d/llvm-base-3.0.0.0-*.conf
Locate this line and delete it:
extra-ghci-libraries: ""
Then run: ghc-pkg recache --user