MSYS2 is recommended on both Haskell Wiki and GHC Wiki.

Hi it's me again with a similar problem as in #5

I'm trying to use the sdl2 package on windows (mostly for developing in (quine)[ekmett/quine]). After some pitfalls I'm able to build the sdl2 package from source and from hackage. My current build flow:

• unpack the SDL2-devel-2.0.3-mingw.tar.gz from https://www.libsdl.org/download-2.0.php into C:\SDL2-2.0.3
• cabal get sdl2
• cd sdl2
• cabal configure --extra-include-dirs="C:\\SDL2-2.0.3\\include" --extra-lib-dirs="C:\\SDL2-2.0.3\\x86_64-w64-mingw32\\lib"
• cabal build

the build is successful but using the lib in an other project results in a build error:

Loading package sdl2-1.3.0 ...
<no location info>:
    <command line>: can't load .so/.DLL for: mingw32.dll (addDLL: could not load DLL)
[49 of 51] Compiling Quine.Geometry.Frustum ( src\Quine\Geometry\Frustum.hs, dist\build\Quine\Geometry\Frustum.o )

<no location info>:
    ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.8.4 for x86_64-unknown-mingw32):
        Dynamic linker not initialised

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

the relevant lines from the SDL pkg-config:

Libs: -L${libdir}  -lmingw32 -lSDL2main -lSDL2  -mwindows
Libs.private: -lmingw32

I believe that there is no mingw32.dll in MinGW. A wild guess: something tries to link dynamically while it should linked statically?

related on SO: http://stackoverflow.com/questions/15996796/haskell-sdl-cant-find-mingw32-dll

I'm a bit lost here. Is this really a ghc bug? Should I report it there? Or is this a bug of this bundle. I'm using the GHC 7.8.4 (64-bit) version of MinGHC.

It's impossible to tell which commit is the basis for the builds available in the README. Better would be to link to the "Releases" section and dynamically add new download links for each "release" as they are available. This way I can know that what I'm installing has or doesn't have certain changes.

When the same version of 32-bit and 64-bit GHC are installed side by side, the switcher script name will be ambiguous between the two. Perhaps we could add -x64 to the end of the 64-bit switcher?

seeing messages like

error opening file for writing
C;\Program Files\MinGHC-7.8.4\bin\alex.exe

etc, for all the various bins in the installer. This is also on a pretty locked down windows box

At least on Windows 8, installing to the default directory, under "C:\Program Files (x86)", fails with "Error opening file for writing." This is presumably because the installer hasn't sought UAC elevation, and that location is not writable with user permissions.

The install generator relies on a number of files hosted on the web. We should have a markdown file which lists the files, and where we have created them ourselves (eg happy.exe) the details of how we created them. If we don't do this soon, I guarantee we'll wish we had some time in future :)

It seems its not possible to build GHC from git with MinGHC.

I'm doing this under Wine on Linux. I do perl boot on Linux, then run the bash.exe shell (from win-bash, not MinGHC, see #39) under Wine and when I try to configure I get:

checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC version date... inferred 7.11.20150409
checking for GHC Git commit id... inferred fc14e124c555e00d73bba461df01a7d8cf9c050d
This configuration does not support the `--srcdir' option..

Is this a known issue? How easy is it to fix?

Thx for minghc, was really looking forward to it.

I had two problems with double-conversion on windows with haskell-platform since my project depends on text-format and so on double-conversion.

the first problem happens when building the project or with this minimal example

-- | Main.hs
module Main where
import Data.Double.Conversion.Text
import Data.Text.Internal
main = print $ showText (toShortest pi)

> cabal install double-conversion
> runhaskell.exe .\Main.hs
...
can't load .so/.DLL for: stdc++.dll (addDLL: could not load DLL)

related issue: haskell/double-conversion#7

the second problem is similar

> cabal get double-conversion
> cd double-conversion
> cabal sandbox init
> cabal install --dep
> cabal repl
...
Loading object (static) dist\build\cbits\hs-double-conversion.o ... ghc.exe: Unknown PEi386 section name `.gcc_except_table' (while processing: dist\build\cbits\hs-double-conversion.o)
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.8.3 for i386-unknown-mingw32):
        loadObj "dist\\build\\cbits\\hs-double-conversion.o": failed

possible related: http://stackoverflow.com/a/13333029

I know, this is not minghc specific but I want to note that this problem still exists (and because I hoped a bit minghc could solve this for me;)). And maybe it makes someone aware of this problem again? This currently blocks me to use my project on the windows platform.

But is there a way to include this custom script from stackoverflow into this minghc, if it makes sense in general and is not to specific.

I tried to use minGHC. I'am working on Windows 7 64 bits. I removed GHC and all packets from my computer as described in https://www.fpcomplete.com/user/varosi/recipes/haskell-on-windows-recipe-1
I installed installed minGHC-7.8.3 (32 bits). Checked the path. cabal has version 1.20.0.3. I didn't add the switcher to the path.
cabal update (a new default config is written)
cabal install alex happy cabal-install-1.20.0.6 and I get errors (see below). minGHC can't compile network-2.0.6.2. What can I do?

Kees

Resolving dependencies...
Configuring network-2.6.0.2...
Configuring alex-3.1.4...
Configuring happy-1.19.5...
Building alex-3.1.4...
Building happy-1.19.5...
Installed alex-3.1.4
Installed happy-1.19.5
Failed to install network-2.6.0.2
Build log ( C:\Users\kees\AppData\Roaming\cabal\logs\network-2.6.0.2.log ):
Configuring network-2.6.0.2...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for an ANSI C-conforming const... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for stdlib.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for unistd.h... (cached) yes
checking winsock2.h usability... yes
checking winsock2.h presence... yes
checking for winsock2.h... yes
checking ws2tcpip.h usability... yes
checking ws2tcpip.h presence... yes
checking for ws2tcpip.h... yes
checking arpa/inet.h usability... no
checking arpa/inet.h presence... no
checking for arpa/inet.h... no
checking netdb.h usability... no
checking netdb.h presence... no
checking for netdb.h... no
checking netinet/in.h usability... no
checking netinet/in.h presence... no
checking for netinet/in.h... no
checking netinet/tcp.h usability... no
checking netinet/tcp.h presence... no
checking for netinet/tcp.h... no
checking sys/socket.h usability... no
checking sys/socket.h presence... no
checking for sys/socket.h... no
checking sys/uio.h usability... no
checking sys/uio.h presence... no
checking for sys/uio.h... no
checking sys/un.h usability... no
checking sys/un.h presence... no
checking for sys/un.h... no
checking for readlink... no
checking for symlink... no
checking for struct msghdr.msg_control... no
checking for struct msghdr.msg_accrights... no
checking for struct sockaddr.sa_len... no
checking for in_addr_t in netinet/in.h... no
checking for SO_PEERCRED and struct ucred in sys/socket.h... no
checking for getpeereid in unistd.h... checking for getpeereid... no
checking for _head_libws2_32_a in -lws2_32... yes
checking for getaddrinfo... no
checking for getaddrinfo if WINVER is 0x0501... yes
checking for gai_strerror... no
checking whether AI_ADDRCONFIG is declared... no
checking whether AI_ALL is declared... no
checking whether AI_NUMERICSERV is declared... no
checking whether AI_V4MAPPED is declared... no
checking whether IPV6_V6ONLY is declared... yes
checking whether IPPROTO_IP is declared... yes
checking whether IPPROTO_TCP is declared... yes
checking whether IPPROTO_IPV6 is declared... yes
checking for sendfile in sys/sendfile.h... no
checking for sendfile in sys/socket.h... no
checking for gethostent... no
checking for accept4... no
configure: creating ./config.status
./configure: line 4864: test: too many arguments
./configure: line 4864: test: too many arguments
./configure: line 4864: test: too many arguments
./configure: line 4864: test: too many arguments
./configure: line 4864: test: too many arguments
./configure: line 4864: test: too many arguments
configure: error: could not make ./config.status
cabal: Error: some packages failed to install:
HTTP-4000.2.19 depends on network-2.6.0.2 which failed to install.
cabal-install-1.20.0.6 depends on network-2.6.0.2 which failed to install.
network-2.6.0.2 failed during the configure step. The exception was:
ExitFailure 1

The experience is yucky because we don't have signatures for our installers. Let's look into it.

When you double-click uninstall.exe in the install directory, the uninstaller freezes while trying to remove the install directory. I assume that's because it's trying to remove itself. Not freezing would be nice. It does give up after a couple minutes, however. So it's not as bad.

I'm pretty sure fixing this would be really low on your list or priorities, but I thought I submit it anyway.

The installer is quite happyt to work under windows and the installed ghc.exe binary can compile a simple "Hello World" program which also runs quite happily under Wine.

However, since I really interested in compiling GHC for Windows under Wine I tried running the bash.exe binary that is installed as part of Msys. Unfortunately that binary just freezes the terminal.

A fresh installation of Windows Server 2008 R2, when minghc-7.8.3 or minghc-7.8.4-x86_64 is installed, running cabal update starts the process but on reaching

Downloading the latest package list from hackage.haskell.org

the following appears

Problem signature:
Problem Event Name: APPCRASH
Application Name: cabal.exe
Application Version: 0.0.0.0
Application Timestamp: 53d6efb8
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7bafa
Exception Code: 40010006
Exception Offset: 0000b727
OS Version: 6.1.7601.2.1.0.272.7
Locale ID: 1033
Additional Information 1: 53cb
Additional Information 2: 53cb7be0fb852ae44dcdf0df9b24117f
Additional Information 3: 993a
Additional Information 4: 993ac5f6525bc97f4b381e31cd2c5591

Tried installing into the default path and a new path. Tried as Administrator or normal user. Tried with custom config from Stackage. All crash in the same way.

Just to confirm that it wasn't a bad download, installing on Windows 7 32-bit & Windows 8 64-bit worked without issue.

After finally upgrading to the Git-powered version of MinGHC, I was disappointed to find that it doesn't include the one thing I was really looking forward to from MSYS2: pacman. Since I was already in a transition state, I decided to grab MSYS2 directly and see how much effort it would be to get everything up and running. My verdict is best summarized as "holy crap, guys."

• The 64-bit version includes the 32-bit MinGW, which looks like a big step toward #52.
• git is available as a pacman package.
• So are sdl/sdl2, gtk, glut, pkg-config... everything in #25, and then some.
• In its shells, its own paths are prepended. Outside, they don't exist. Relevant to #53 and #18.

That's not to say there are no downsides at all. Potential complications I noticed:

• The installer provides only a minimum context for running pacman. Even after following the instructions behind that link, it doesn't include the gcc toolchain. Fetching it would have to be scripted.
• The pacman-fetched git is not available at a regular Windows prompt. If we don't want to require use of bash for stackage, it'll still be necessary to install regular GitForWindows. However, there would be no reason to expose the existence of GitBash; MSYS2 encompasses and supercedes that.
• MSYS and MinGW have separate shells (plus a third for 32-bit with the 64-bit installation). MinGW is for stuff that requires the GNU toolchain; MSYS is for stuff that requires a full POSIX subsystem, and it's recommended to avoid this unless absolutely necessary because there's a cost for that emulation layer. Very little in the Haskell ecosystem requires the latter -- network does fine with just MinGW -- but some might... and sadly, pacman does. So I think both shells would need to be exposed, which means explaining the difference to the user.

Edit: Looks like using a path-switching command file (as MinGHC currently does), or if you're lazy like me just appending msys64\usr\bin and msys64\mingw64\bin to path, lets you stick with a standard Windows shell for pretty much everything but pacman. Cabal can find sh, there's no need for an additional Git4Win installation, pkg-config even works correctly for libraries installed via pacman.

Sometimes we need to install 32-bit GHC on 64-bit Windows. It would be helpful to have this option, or to have two separate installers, one for each arch.

First, the horror story: for convenience, I had msys-1.0.1\home\tejon linked to my data drive, D:\. Note that Windows only permits "junctions" (soft links) of directories; in Explorer this is represented with a different icon from other folders, and it can be moved or deleted/recycled without affecting the link target. You can probably guess the story: I started the MinGHC uninstall, and a few minutes later there was a moment of panic when I checked progress and saw what files were being deleted! Luckily it hit my massive last-four-harddrives backup folder first, so nothing I've touched in at least a year was affected; and more luckily, Recuva hasn't thrown a single error yet while undeleting.

This in and of itself is a pretty huge issue (though it might be intrinsic to NSIS), but it made me think about some previous MinGHC un/reinstalls and the fact that when I use MinGW to build something, I generally make install and everything goes right where it should in the MSYS hierarchy. Is it necessary that I have to delete and rebuild it all, to get a clean MinGHC install? A lot of installers remember what they put there, and don't remove anything they didn't.

Granted this all started because I've put off updating for a while due to a project in progress; I don't know if the new Git dependency obviates the whole topic.

If you install MinGHC it adds $APPDATA/cabal/bin to the PATH. Using MinGHC then probably puts things on that PATH. Uninstalling MinGHC doesn't touch $APPDATA because any other GHC installations might have touched it. Maybe we should offer to remove it from the PATH and clean it out? Maybe that's just inviting user mistakes?

If we used this NSIS plugin, we could make the installer much less noisy for unpacking 7z files.

http://nsis.sourceforge.net/Nsis7z_plug-in

• If a user modifies the PATH, we should tell them to start a shell and use GHC.
• If a user adds the switcher, we should tell them how to run it.
• If the user doesn't add the switcher, we should tell them how to run it with the full PATH.

Linking dist/dist-sandbox-ca386853\build\idris\idris.exe ...
...\proj\haskell\idris\.cabal-sandbox\i386-windows-ghc-7.8.3\network-2.6.0.2/libHSnetwork-2.6.0.2.a(HsNet.o):HsNet.c:(.text+0x1c): undefined reference to `getnameinfo'
...\proj\haskell\idris\.cabal-sandbox\i386-windows-ghc-7.8.3\network-2.6.0.2/libHSnetwork-2.6.0.2.a(HsNet.o):HsNet.c:(.text+0x28): undefined reference to `getaddrinfo'
...\haskell\idris\.cabal-sandbox\i386-windows-ghc-7.8.3\network-2.6.0.2/libHSnetwork-2.6.0.2.a(HsNet.o):HsNet.c:(.text+0x34): undefined reference to `freeaddrinfo'
collect2: ld returned 1 exit status
cabal.exe: Error: some packages failed to install:
idris-0.9.17.1 failed during the building phase. The exception was:
ExitFailure 1

Do I need to pass additional flags to cabal? I am building from inside a MSYS2 terminal. Not sure if that could cause confusion.

@snoyberg @DanBurton Major problem: stackage sandbox init was broken for [probably] all snapshots. stackage sandbox looks for the string "-- Stackage snapshot from: http://www.stackage.org/snapshot/" in cabal.config but the server now gives a URL without the snapshot/ path. We can't fix this in stackage sandbox alone because countless people already have the current version installed, as we package it with MinGHC. I filed the bug here: fpco/stackage-sandbox#4

At the moment to setup Stackage you need wget on your PATH (not available as standard with Windows, although pretty easy to get) and you need to remember the URL. We could make that better by doing one of:

• Ship wget.exe and a stackage.bat file that does the appropriate command line.
• Have a stackage.exe binary (probably backed by a Cabal package on Hackage) that links in network and defaults to the right URL (that seems useful anyway). This could have more smarts, and wouldn't require wget.

Not sure if this should be moved to the Stackage tracker...

In particular, I'm thinking about the default to only vanilla libraries. That's a lot of painful reinstalling if you don't know, or forget, to change it immediately. http://www.vex.net/~trebla/haskell/cabal-cabal.xhtml makes good suggestions in general.

I'm not 100% sure this is in scope for minghc, since it doesn't seem to otherwise make any modifications to individual packages; but it does fit the guiding theme IMO.

I'm not sure how far we can go with this, but git's ancillary tools overlap with Windows built-in tools. For example, the packaged git's ./usr/bin folder has echo, find, [.exe (??), dir, etc. These overlap with the standard Windows commands with the same name (except for [...that's just weird). Does git actually need these on the path to work? Even if it does, we need to figure out a way to stop these from polluting the PATH. I have simple Windows scripts that don't work when MinGHC paths are set.

I started off yesterday playing with the idea of bundling Git with MinGHC. A bunch of changes in that direction are on the git branch. Unfortunately going down this path ended up raising a lot of tangential issues, so I'd like to raise them here for discussion.

• Currently our msys is based on the older msys1, while most people are moving to msys2 (related: #20 #40). It seems that PortableGit includes msys2 (which is how I ended up with the weird network issue today).
  • One option is to include PortableGit and put its msys on the PATH. However, this won't expose the pacman installer, which some people may want.
  • Another option is to include msys2 itself, but that would mean (1) we wouldn't get Git, and would have to maintain our own bundle, since msys2 is only available via an installer.
  • And then of course we have option 3 of sticking with msys1. It's worth pointing out that msys1 is significantly smaller in size than the other two (they both take ~40MB compressed).
• PortableGit is distributed as a 7z archive. It's easy to move around the 7z.exe and 7z.dll files for decompression. On the git branch, I took the approach of bundling the .7z archives in the installer itself, together with 7z.exe and 7z.dll, and then decompressing from the nsis script. This makes the executable creation process faster, and reduces dependencies on the build system (no need for bzip2, gzip, or bsdtar).
• Another change I made to simplify setup was to move to http-client for doing the downloads instead of shelling out to wget. This change is completely orthogonal to others, and I don't feel strongly about it at all (85bfde5).
• Permissions issues are a problem (#2). With PortableGit, we have to install to a user-writable place so that the /tmp directory is writable. I solved this by installing everything into $HOME/AppData/Roaming/minghc-7.10.1-i386. I'm leaning towards this being a good idea as opposed to just a hack to get PortableGit working.
• Issue #19 requested better Stackage support, which means bundling the new stackage-cli tools. That, combined with cabal, alex, happy, and things we add in the future, will lead to a lot of things to keep track of. Instead, I set things up with a single .7z archive containing all of the executables, which seems like an easier thing to manage.

Sorry for the large, all-at-once braindump. I thought I'd be able to play with just Git, but I ended up unraveling many other things.

It would be nice to not have redundant installations around if I've already got MSYS2/MINGW set up nicely.

We have 7.8.4 for 64-bit, but not 32-bit

Trying to install haskell-src-exts I ended up with:

happy.exe: C:\Documents and Settings\IEUser\Application Data\cabal\i386-windows-
ghc-7.8.3\happy-1.19.4/HappyTemplate-arrays-coerce: openFile: does not exist (No
 such file or directory)

I'd already installed haskell-src-exts, but this time I was doing it with cabal from the directory, rather than with cabal install haskell-src-exts, which might make a difference? Either way, something worth looking at, since we don't ship the happy data files.

Unsure what is problem vs symptom here.

Motivation: language-c is a requirement of c2hs (which is a requirement of opencl). It fails to install.

My system: fresh Windows 10 with MinGHC for GHC7.10.1 64bit. The only other packages installed are cabal install alex, happy and network, which all were installed ok. No cygwin, everything done in Windows command window.

The alex.exe in C:\Program Files\MinGHC-7.10.1\bin is 3.1.3.
The alex.exe in C:\Users\FinnEspen\AppData\Roaming\cabal\bin is alex 3.1.4.

Build log:

C:\Users\FinnEspen>cabal install language-c
Resolving dependencies...
Configuring language-c-0.4.7...
Building language-c-0.4.7...
Failed to install language-c-0.4.7
Build log ( C:\Users\FinnEspen\AppData\Roaming\cabal\logs\language-c-0.4.7.log ):
Building language-c-0.4.7...
Preprocessing library language-c-0.4.7...
alex.exe: C:\Documents and Settings\IEUser\Application Data\cabal\i386-windows-ghc-7.8.3\alex-3.1.3/AlexTemplate-ghc-nopred: openFile: does not exist (No such file or directory)
cabal: Error: some packages failed to install:
language-c-0.4.7 failed during the building phase. The exception was:
ExitFailure 1

Note that alex complains about a non-existing path (there is no IEUser) and is looking for something belonging to the i386 version of ghc 7.8.3 - which has never been installed.

Last time I had similar troubles while building Idris (#32) which was resolved by building under a Command Prompt, this time not so lucky. The error messages are similar:

In-place registering pandoc-1.13.2.1...
Preprocessing executable 'pandoc' for pandoc-1.13.2.1...
[1 of 1] Compiling Main             ( pandoc.hs, dist\dist-sandbox-ad34cd67\build\pandoc\pandoc-tmp\Main.o )
Linking dist/dist-sandbox-ad34cd67\build\pandoc\pandoc.exe ...
...\proj\haskell\hakyll\.cabal-sandbox\i386-windows-ghc-7.8.3\network-2.6.0.2/libHSnetwork-2.6.0.2.a(HsNet.o):HsNet.c:(.text+0x1c): undefined reference to `getnameinfo'
...\proj\haskell\hakyll\.cabal-sandbox\i386-windows-ghc-7.8.3\network-2.6.0.2/libHSnetwork-2.6.0.2.a(HsNet.o):HsNet.c:(.text+0x28): undefined reference to `getaddrinfo'
...\proj\haskell\hakyll\.cabal-sandbox\i386-windows-ghc-7.8.3\network-2.6.0.2/libHSnetwork-2.6.0.2.a(HsNet.o):HsNet.c:(.text+0x34): undefined reference to `freeaddrinfo'
collect2: ld returned 1 exit status

In the Idris case I was building off a local git clone of Idris, while this time I am running a straight cabal install. Don't know if that made the difference.

Since I saw on the Readme.md that there is a willingness to ship with additional, precompiled third party libraries, what is the opinion about including sqlite3? It would be my pleasure to create a PR for this effort. The library installation is pretty straightforward, and as such it could function as a nice "test case" on the process of including additional C libraries with minghc.

On the other hand, it might make the bundling process more complex, which is undesirable (this is not Haskell Platform after all).

I am curious what the vision of the maintainers is regarding these things.

Tried it on Windows 7 Pro, steps:

1. Install to C:\haskell
2. cabal update
3. cd C:\haskell\test.sandbox
4. cabal sandbox init
5. cabal install network

Result:

C:\haskell\test.sandbox>cabal install network
Resolving dependencies...
Notice: installing into a sandbox located at
C:\haskell\test.sandbox.cabal-sandbox
Configuring network-2.6.0.2...
Failed to install network-2.6.0.2
Build log ( C:\haskell\test.sandbox.cabal-sandbox\logs\network-2.6.0.2.log ):
Configuring network-2.6.0.2...
setup-Configure-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: does not exist
cabal.EXE: Error: some packages failed to install:
network-2.6.0.2 failed during the configure step. The exception was:
ExitFailure 1

This is an issue is because GLUT is in the Haskell Platform, and most of the answers on the internet I found told you to just install the HP.

I actually 'accidentally' fixed my problem while working on typing up this issue's details. So I'll list the steps I took so at the least this issue itself will provide documentation.

I used the freeglut binaries from http://www.transmissionzero.co.uk/software/freeglut-devel/

The ghc looks under "C:\Program Files\MinGHC-x.y.z\ghc.x.y.z\mingw" in the lib and include subdirectories for the c libraries and include files. (I didn't find this explicitly documented anywhere)

The key thing I find basically by accident is you must copy(rename?) libfreeglut.a to libglut32.a

This gets GLUT to install fine. Unfortunately I can't actually test if it works properly since gloss doesnt support ghc 7.10 yet (base == 4.7.* dependency) [Tested a basic program with 7.8.4 64bit and it runs fine once I remembered to install the DLL]

I'm not sure how to apply this to the x64 ghc's dirs either. It looks like for 64bit you need to put the x64bit freeglut librarys under mingw\x86_64-w64-mingw32\ instead of just mingw.

[Edit: You also need rename the DLL to glut32.dll and put it in the directory with your project. It didn't seem to work when I put it in the system directories, but maybe I did something wrong]

I've seen this twice now. If you do some manual PATH munging to get MinGHC on a non-admin account, you are then met with

C:\Users\Child>cabal update
C:\Users\Child>cabal install network

...

    When checking declaration:
      foreign import stdcall unsafe "static WSAGetLastError" c_getLastError
        :: IO CInt

NetworkSocketInternal.hsc:177:3: Warning:
    A do-notation statement discarded a result of type `a'
    Suppress this warning by saying
      `_ <- throwSocketErrorIfMinus1Retry name act'
    or by using the flag -fno-warn-unused-do-bind
[4 of 9] Compiling Network.Socket   ( dist\build\Network\Socket.hs, dist\build\N
etwork\Socket.o )

NetworkSocket.hsc:177:1: Warning:
    The import of `delete' from module `Data.List' is redundant

NetworkSocket.hsc:182:1: Warning:
    The import of `Foreign.C.Error' is redundant
      except perhaps to import instances from `Foreign.C.Error'
    To import instances alone, use: import Foreign.C.Error()

NetworkSocket.hsc:184:1: Warning:
    The import of `CUInt' from module `Foreign.C.Types' is redundant

NetworkSocket.hsc:187:1: Warning:
    The import of `Foreign.Marshal.Array' is redundant
      except perhaps to import instances from `Foreign.Marshal.Array'
    To import instances alone, use: import Foreign.Marshal.Array()

NetworkSocket.hsc:198:1: Warning:
    The import of `threadWaitRead' from module `GHC.Conc' is redundant

NetworkSocket.hsc:247:1: Warning:
    Top-level binding with no type signature: socket2FD :: Socket -> FD

NetworkSocket.hsc:420:9: Warning:
    Defined but not used: `connectBlocked'

NetworkSocket.hsc:619:21: Warning: Defined but not used: `s'

NetworkSocket.hsc:641:24: Warning: Defined but not used: `s'

NetworkSocket.hsc:671:24: Warning: Defined but not used: `s'

NetworkSocket.hsc:705:27: Warning: Defined but not used: `s'

NetworkSocket.hsc:1017:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static htonl" htonl
        :: Word32 -> Word32

NetworkSocket.hsc:1548:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static inet_addr" c_inet_addr
        :: Ptr CChar -> IO HostAddress

NetworkSocket.hsc:1551:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static shutdown" c_shutdown
        :: CInt -> CInt -> IO CInt

NetworkSocket.hsc:1561:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static closesocket" c_close
        :: CInt -> IO CInt

NetworkSocket.hsc:1565:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static socket" c_socket
        :: CInt -> CInt -> CInt -> IO CInt

NetworkSocket.hsc:1567:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static bind" c_bind
        :: CInt -> Ptr SockAddr -> CInt -> IO CInt

NetworkSocket.hsc:1569:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall safe "static connect" c_connect
        :: CInt -> Ptr SockAddr -> CInt -> IO CInt

NetworkSocket.hsc:1571:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static accept" c_accept
        :: CInt -> Ptr SockAddr -> Ptr CInt -> IO CInt

NetworkSocket.hsc:1571:1: Warning: Defined but not used: `c_accept'

NetworkSocket.hsc:1577:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static listen" c_listen
        :: CInt -> CInt -> IO CInt

NetworkSocket.hsc:1581:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall safe "static accept" c_accept_safe
        :: CInt -> Ptr SockAddr -> Ptr CInt -> IO CInt

NetworkSocket.hsc:1587:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static send" c_send
        :: CInt -> Ptr a -> CSize -> CInt -> IO CInt

NetworkSocket.hsc:1587:1: Warning: Defined but not used: `c_send'

NetworkSocket.hsc:1589:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall safe "static sendto" c_sendto
        :: CInt
           -> Ptr a -> CSize -> CInt -> Ptr SockAddr -> CInt -> IO CInt

NetworkSocket.hsc:1591:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static recv" c_recv
        :: CInt -> Ptr CChar -> CSize -> CInt -> IO CInt

NetworkSocket.hsc:1591:1: Warning: Defined but not used: `c_recv'

NetworkSocket.hsc:1593:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall safe "static recvfrom" c_recvfrom
        :: CInt
           -> Ptr a -> CSize -> CInt -> Ptr SockAddr -> Ptr CInt -> IO CInt

NetworkSocket.hsc:1595:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static getpeername" c_getpeername
        :: CInt -> Ptr SockAddr -> Ptr CInt -> IO CInt

NetworkSocket.hsc:1597:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static getsockname" c_getsockname
        :: CInt -> Ptr SockAddr -> Ptr CInt -> IO CInt

NetworkSocket.hsc:1600:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static getsockopt" c_getsockopt
        :: CInt -> CInt -> CInt -> Ptr CInt -> Ptr CInt -> IO CInt

NetworkSocket.hsc:1602:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static setsockopt" c_setsockopt
        :: CInt -> CInt -> CInt -> Ptr CInt -> CInt -> IO CInt

NetworkSocket.hsc:278:3: Warning:
    Pattern match(es) are non-exhaustive
    In an equation for `showsPrec':
        Patterns not matched:
            _ (SockAddrUnix _)
            _ (SockAddrCan _)
[5 of 9] Compiling Network.Socket.ByteString ( dist\build\Network\Socket\ByteStr
ing.hs, dist\build\Network\Socket\ByteString.o )

NetworkSocketByteString.hsc:51:1: Warning:
    The import of `Foreign.C.Types' is redundant
      except perhaps to import instances from `Foreign.C.Types'
    To import instances alone, use: import Foreign.C.Types()

NetworkSocketByteString.hsc:54:1: Warning:
    The import of `SockAddr, Socket'
    from module `Network.Socket' is redundant

NetworkSocketByteString.hsc:94:6: Warning:
    Defined but not used: `sock'
[6 of 9] Compiling Network.Socket.ByteString.Lazy.Windows ( Network\Socket\ByteS
tring\Lazy\Windows.hs, dist\build\Network\Socket\ByteString\Lazy\Windows.o )
[7 of 9] Compiling Network.Socket.ByteString.Lazy ( Network\Socket\ByteString\La
zy.hs, dist\build\Network\Socket\ByteString\Lazy.o )
[8 of 9] Compiling Network.BSD      ( dist\build\Network\BSD.hs, dist\build\Netw
ork\BSD.o )

NetworkBSD.hsc:105:1: Warning:
    The import of `CUInt' from module `Foreign.C.Types' is redundant

NetworkBSD.hsc:109:1: Warning:
    The import of `fromBool'
    from module `Foreign.Marshal.Utils' is redundant

NetworkBSD.hsc:162:43: Warning:
    In the use of data constructor `PortNum'
    (imported from Network.Socket, but defined in Network.Socket.Types):
    Deprecated: "Do not use the PortNum constructor. Use the Num instance. PortN
um will be removed in the next release."

NetworkBSD.hsc:185:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static getservbyname" c_getservbyname
        :: CString -> CString -> IO (Ptr ServiceEntry)

NetworkBSD.hsc:190:19: Warning:
    In the use of data constructor `PortNum'
    (imported from Network.Socket, but defined in Network.Socket.Types):
    Deprecated: "Do not use the PortNum constructor. Use the Num instance. PortN
um will be removed in the next release."

NetworkBSD.hsc:196:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static getservbyport" c_getservbyport
        :: CInt -> CString -> IO (Ptr ServiceEntry)

NetworkBSD.hsc:282:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static getprotobyname" c_getprotobyname
        :: CString -> IO (Ptr ProtocolEntry)

NetworkBSD.hsc:292:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static getprotobynumber" c_getprotobynumber

        :: CInt -> IO (Ptr ProtocolEntry)

NetworkBSD.hsc:383:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall safe "static gethostbyname" c_gethostbyname
        :: CString -> IO (Ptr HostEntry)

NetworkBSD.hsc:397:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall safe "static gethostbyaddr" c_gethostbyaddr
        :: Ptr HostAddress -> CInt -> CInt -> IO (Ptr HostEntry)

NetworkBSD.hsc:555:1: Warning:
    the 'stdcall' calling convention is unsupported on this platform,
    treating as ccall
    When checking declaration:
      foreign import stdcall unsafe "static gethostname" c_gethostname
        :: CString -> CSize -> IO CInt

NetworkBSD.hsc:564:1: Warning: Defined but not used: `getEntries'
[9 of 9] Compiling Network          ( Network.hs, dist\build\Network.o )

Network.hs:292:16: Warning:
    Pattern match(es) are non-exhaustive
    In a case alternative:
        Patterns not matched:
            SockAddrUnix _
            SockAddrCan _

Network.hs:401:5: Warning:
    Pattern match(es) are non-exhaustive
    In a case alternative:
        Patterns not matched:
            SockAddrUnix _
            SockAddrCan _
In-place registering network-2.6.2.0...
cabal: Error: some packages failed to install:
network-2.6.2.0 failed while downloading the package. The exception was:
DeleteFile
"C:\\Users\\Child\\AppData\\Local\\Temp\\network-2.6.2.0-1632\\network-2.6.2.0\\
conf4360.lnk":
permission denied (Access is denied.)

Tested with a fresh, clean user named Test to rule out any weirdness with my existing user folders (and there certainly is some).

it appears that %user%\AppData\Roaming\cabal is not created at all, though *\bin is correctly added to the local user's PATH var. There's no cabal.exe anywhere else in the path, either.

(I don't quite understand why cabal.exe gets buried in user files, but that's an unrelated topic.)

Hey,

I tried installing minghc on two separate win7 Machines, both times avira antivir pops up complaining about dropper/gen trojan. I can not provide additional Information on which file it happened since Corporate policy locks the Computer up on Security alerts.

Is that a known problem? I will try to gain additional Information later.

(on my phone)

It could be advantageous for some [like myself] to have a single installer for both architectures. This would allow for easily sharing the same install of MSYS, Git, and other ancillary tools (stackage-cli, etc.).

My particular use-case is not building exes but shared dlls which have the inconvenient property that they can only be dynamically loaded by apps who have matching architecture. My app happens to run on the native architecture so I need dlls in both.

Blocked on haskell/cabal#2279

Thanks for this installer. Really makes my life on Windows a lot more pleasant.

Just wondering if owner/users would be interested PRs for tricky package installs for say, GTK2/3 and SDL? Seem to be common sore points.

Cheers.

I tried 'minghc-7.8.3' for 64bit version on Windows 8.1.

I noticed that the path for "%APPDATA%\cabal\bin" is added as the last one. Since updated cabal.exe will be installed there when we do cabal install cabal-install, I think it might be better to add %APPDATA%\cabal\bin as the first one. If not, windows will always find the old cabal.exe installed in ...\MinGHC-7.8.3\bin.

From running stack build on the stackage-server repo, lts-2.10.

happy-1.19.5: build: ERROR
Stdout was:
Building happy-1.19.5...
Preprocessing executable 'happy' for happy-1.19.5...

Stderr was:
Setup.lhs: The program happy is required but it could not be found

I tried to build data-default-instances-old-locale version 0.0.1 on Windows. I got the following error message:

~ $ cabal install data-default-instances-old-locale
Resolving dependencies...
Configuring data-default-instances-old-locale-0.0.1...
Building data-default-instances-old-locale-0.0.1...
Failed to install data-default-instances-old-locale-0.0.1
Build log ( C:\Users\gl67\AppData\Roaming\cabal\logs\data-default-instances-old-locale-0.0.1.log ):
Building data-default-instances-old-locale-0.0.1...
Preprocessing library data-default-instances-old-locale-0.0.1...
[1 of 1] Compiling Data.Default.Instances.OldLocale ( Data\Default\Instances\OldLocale.hs, dist\build\Data\Default\Instances\OldLocale.o )
C:\Users\gl67\repos\MinGHC\7.10.1\ghc-7.10.1\mingw\bin\ar.exe: dist\build\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a-11336\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a: No such file or directory
cabal.exe: Error: some packages failed to install:
data-default-instances-old-locale-0.0.1 failed during the building phase. The
exception was:
ExitFailure 1

I can install data-default-instances-old-locale with ghc 7.10.1 on Linux (Debian) and no such error happened, it seems that MinGHC has some restrictions in locating the compiled objects.

I opened this here: https://ghc.haskell.org/trac/ghc/ticket/10454#comment:1

in case its not minghc specific.

ghc.exe: warning: _tzset from msvcrt is linked instead of __imp__tzset
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup
ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup
ghc.exe: warning: accept from ws2_32 is linked instead of __imp_accept
ghc.exe: warning: inet_ntoa from ws2_32 is linked instead of __imp_inet_ntoa
ghc.exe: warning: getnameinfo from ws2_32 is linked instead of __imp_getnameinfo
ghc.exe: warning: getaddrinfo from ws2_32 is linked instead of __imp_getaddrinfo
ghc.exe: warning: freeaddrinfo from ws2_32 is linked instead of __imp_freeaddrinfo
ghc.exe: warning: LeaveCriticalSection from kernel32 is linked instead of __imp_LeaveCriticalSection
ghc.exe: warning: EnterCriticalSection from kernel32 is linked instead of __imp_EnterCriticalSection
ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection
ghc.exe: warning: DeleteCriticalSection from kernel32 is linked instead of __imp_DeleteCriticalSection
ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection
ghc.exe: warning: InitializeCriticalSection from kernel32 is linked instead of __imp_InitializeCriticalSection

OS: WIndows 8.1 x64
Install everything without modifying PATH, then from windows cmd: minghc-7.8.3.bat && cabal install network.
Output is:

Resolving dependencies...
Configuring network-2.6.0.2...
0 [main] "sh" 7456 sync_with_child: child 10844(0x168) died before initialization with status code 0xC0000142
458 [main] "sh" 7456 sync_with_child: *** child state waiting for longjmp
./configure: fork: Resource temporarily unavailable
Failed to install network-2.6.0.2

I was messing with the PATH setting and now my Msys won't launch saying: Windows cannot find file:'C:\Program'. I'd like to delete my .bashrc or whatever is causing that start over.

I even tried un-installing via uninstall.exe

Any help is appreciated.

From #6: minghc didn't register itself in Windows' "Add or remove programs", so I had to run uninstall.exe by hand.

Needs adding there, and removing from there on uninstall. Annoying, but not too hard.

I have a plain new installation of MinGHC 7.10.1 and I have tried to install the dependencies of my cabal sandbox when, suddenly, I get the following message:

$ cabal repl
Preprocessing executable 'myproject' for myproject-0.1.0.0...
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
ghc.exe: unable to load package `network-2.6.0.2'
ghc.exe: C:\directory-of-project\.cabal-sandbox\i386-windows-ghc-7.10.1\netwo_7d76Yx3J1NVCM4gO06psKu\HSnetwork-2.6.0.2-7d76Yx3J1NVCM4gO06psKu.o: unknown symbol `_shutdownWinSock'

The same problem happened when I have installed the MinGHC 7.8.3.