I was able to cabal install text-icu without errors. (I used --extra-lib-dirs and --extra-include-dirs to point to the lib and include directories in the binary distribution of icu4c.)
I was also able to build the following simple program that uses text-icu, by doing ghc --make icu.hs:
-- icu.hs
import Data.Text.ICU
main = print $ Locale "tr-TR"
No errors or warnings in either of these steps. But when I try to run the compiled program, icu.exe, I get no output at all. I expected to get a line with Locale "tr-TR", but instead I get nothing -- not even an error or warning. This remains the case if I try
main = do
print $ Locale "tr-TR"
print "Done"
so using the text-icu stuff seems to cause the program to silently fail. echo $? yields False.
Does anyone have text-icu up and running on Windows? Can you tell me what I'm doing wrong?
Stack includes a copy of msys2 on Windows, which contains the pacman package manager, so we can run:
stack exec -- pacman -Sy mingw64/mingw-w64-x86_64-icu
stack build text-icu
I managed it by doing:
Download the binaries from http://site.icu-project.org/download/56#TOC-ICU4C-Download, specifically http://download.icu-project.org/files/icu4c/56.1/icu4c-56_1-Win32-msvc10.zip.
Extract the contents of icu/bin into the directory C:\bin which is on my %PATH%. Extract the contents of icu into the directory C:\bin\icu.
Use Stack to run stack ghci text-icu --extra-lib-dirs=c:\bin --extra-include-dirs=c:\bin\icu\include.
In GHCi, run import Data.Text.ICU.Normalize, then :set -XOverloadedStrings, then normalize None "test".
For each dll that is reported as cannot be found, e.g. icuuc.dll, take the C:\bin\icuuc56.dll and make a copy at C:\bin\icuuc.dll. For me, there were three relevant dlls.
After all that, I can normalise a string in ghci.
This is how windows reacts to a missing static dependency. When the operating system starts a process it looks for static dependencies. If one is missing, then program is not started.
Use depends.exe to find out what import is missing. That could be a missing dll or one that is the wrong version.
Depends is available with
1. Visual Studio
2. The Microsoft Platform SDK
3. Other microsoft packages
4. http://www.dependencywalker.com
It pretty indispensable when tracking down what is happening in this case.
you should check if there are some DLL missing with cygcheck.check the path and the windows enviroment variables too with it is right. Or try to reinstall following the haskell procedure.
http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation
good luck
Related
I am attempting to set up GTK3 for development on Windows 10 following the instructions on tarnyko.net
using the 64bit 3.6.4 bundle from here. The test program currently builds without errors, using the generated options. When I run the program a dialog appears displaying the error message:
Procedure entry point deflateSetHeader could not be located in the
synamic link library C:\Gtk\bin\libgio-2.0.0.dll
From what I can tell so far, deflateSetHeader is a function in zlib that was not present in older versions - a possible cause for the error. Looking in the header file of zlib that came with Gtk, it lists the function.
I have copies of zlib1 in my Gtk bin dir and MinGW (GCC v7.2.0) bin dir.
I tried swapping the versions between directories, but no joy. Don't have much else in my environment path variable, except for a vanilla Python 3.6 install. Don't have zlib1 in SysWOW64. I tried adding -lzlib1 to my gcc compiler options, but that didn't seem to make a difference. I'm running out of ideas now.
Anyone know what might be causing this?
Found the cause by searching my C drive for zlib and found a copy in
C:\Program Files\Intel\WiFi\bin that was causing the problem.
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 am learning to build a compiler using LLVM as back end.
I followed the steps on getting started with the LLVM system until setting up your environment
What is the specific location for [/path/to/your/bitcode/libs] ?
Was this mistake cause the command not found when I type in lli in a Terminal?
//I am trying to build a hello world to see through the total compiling procedure
You can put LLVM_LIB_SEARCH_PATH wherever you want. For now, you probably don't need to worry about it at all; as the documentation says, it is optional. Later, you may create bitcode (i.e. compiled VM code) functions which you would like to link into the bitcode your compiler produces. For example, you may need to create some kind of standard library and runtime environment for your executables.
That has nothing to do with the lli not found error, which is the result of the LLVM binaries either not having been installed, or having been installed somewhere which is not in your $PATH.
By default, the llvm package will configure itself for installation under the prefix /usr/local, which means that after you gmake install you should find lli and friends in places like /usr/local/bin/lli. That may or may not be in your $PATH; to find out, type
echo "$PATH"
and see if it has :/usr/local/bin: somewhere in it. If it doesn't, then you could change your PATH:
export PATH="/usr/local/bin:$PATH"
To make that permanent, you'll have to add it to your bash startup files.
But you might not want it to be installed there. I usually install software I'm playing with in my local directory tree, so that I don't have to sudo all the time. You can change the root of the installation directory tree with the --prefix argument to ./configure. (You have to do that before you build LLVM.) ./configure --help will provide some more information about configure options, but --prefix is certainly the most important one.
Whatever you do, don't do it blindly. Make sure you understand what this all means before doing it. If you plan on making a compiler, you'll need to understand some of the details of a typical build- and runtime- environment; PATH and configure scripts are on the unfortunately long list of things you should at least be somewhat familiar with.
As I understand it, some version of LLVM is already installed on Mac OS X, so you'll need to be careful that your installation doesn't interfere. The fact that bash is report that lli can't be found probably indicates that not all the tools are installed, which will make things less complicated.
I'm afraid that I don't really have any experience with installing LLVM on a Mac, but if you run into specific problems (like "my compiler doesn't work after I install LLVM") then you could ask a specific question with appropriate tags.
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
I've successfully built a demo app using opencv on windows with the MSYS shell environment.
I did NOT use the prebuilt opencv installer, I downloaded and compiled the source locally (this is the recommended method).
After building opencv and running make install, all the files are happily in:
/e/deps/libopencv/build/install/
I can successfully build a sample application against this using cmake directives along the lines of:
find_package(OPENCV REQUIRED)
link_directory(${OpenCV_LIB_DIR})
include_directories(${OpenCV_INCLUDE_DIRS})
target_link_libraries(target ${OpenCV_LIBS})
To be completely clear here: building the binary is successful.
Now, when I run it from the shell I get the message:
The program can't start because libopencv_core231.dll is missing from your computer.
Try reinstalling the program to fix this problem.
So... I know where the libraries are:
$ ls /e/deps/libopencv/build/install/lib/
libopencv_calib3d231.dll.a libopencv_features2d231.dll.a libopencv_highgui231.dll.a libopencv_ml231.dll.a libopencv_video231.dll.a
libopencv_contrib231.dll.a libopencv_flann231.dll.a libopencv_imgproc231.dll.a libopencv_objdetect231.dll.a
libopencv_core231.dll.a libopencv_gpu231.dll.a libopencv_legacy231.dll.a libopencv_ts231.a
What now?
I guess I could try to make cmake build a static binary, but that seems pretty extreme.
How can I somehow make either 1) windows, or 2) the MSYS environment happy. Something like LD_LIBRARY_PATH on windows?
Or is this not the problem, and I've actually (despite appearances) somehow messed up the way the binary was compiled?
Edit:
NB. For whatever reason it seems that my libraries are .dll.a files, not .dlls (see the ls result) if that's remotely relevant.
windows searches the same directory as the exe, any directory in the %PATH% (Windows) or $PATH (msys) directories, as well as a few special ones in the windows folder
You could add /e/deps/libopencv/build/install/lib to your $PATH. I am not sure if this will work for msys, you may need to add E:\deps\libopencv\build\install\lib to %PATH% in windows instead.
The typical solution for this if you are giving the program to others is to include a copy of the DLL in the same directory as the EXE. you can get this same effect by making a symbolic link to it with the command
ln -s /e/deps/libopencv/build/install/lib/libopencv_core231.dll libopencv_core231.dll
while in the /e/deps/libopencv/build/install/ directory