Robin We would be thrilled if you would help.
We physically include very selective chunks of MinGW in a GHC Windows distribution - so that users don't need to install MinGW - so that GHC doesn't break just because a user has a different version of MinGW than we expected We keep these chunks of MinGW in the GHC repo (in ghc-tarballs) precisely so that we know exactly which bits to ship. The intention is that the MinGW bits shipped with GHC are essentially invisible to the user. They just see a ghc.exe, which just happens internally to call some Mingw binaries. But as you point out, it's not quite invisible if the GHC-compiled stuff has to be compatible in some way with stuff compiled some other way. One route is to use GHC as your C compiler (which will in turn invoke the private MinGW binary), but that probably won't work; I have learned that things are Never Simple. Moreover, it would be great to update the MinGW bits to a more modern version. If you can do this, fantastic. What you need to do, I think, is - look at what is in ghc-tarballs - pull out selected bits of the new MinGW and use them to replace what's in ghc-tarballs - test thoroughly I'm sure that others will be happy to help. Do keep ghc-devs posted. You could make a ticket and post information to it as you learn about it. Or even a wiki page to describe the process, so that in four years time when someone wants to do the same thing, they have a guide. Speaking of which, do search the Trac Wiki in case someone *has* already docuemented some aspects of this. I would really like to have a Windows Strike Force who collectively take responsibility for the Windows port of GHC, if you and some others felt able to be part of such a thing. Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:[email protected]] On Behalf Of Robin | KAY | Sent: 10 June 2014 00:46 | To: [email protected] | Subject: GHC MinGW distribution | | Dear All, | | I wanted to enquire about the prospects for updating the version of | MinGW which ships with the Windows binary distribution of GHC. The | version included as of 7.8.2 is now several years old and in some cases | I've found that it's incompatible with the libraries produced by newer | versions of MinGW (as to be expected, per my understanding). | | Specifically, my HsQML binding for Qt can't be used with the libraries | from the official Windows binary distribution of Qt 5 because the | resulting executables crash on start-up with runtime incompatibilities. | I'm in the process of trying to build out-of-the-box compatible Qt | binaries against GHC's MinGW, but Qt's stated minimum requirements on | the tool-chain version aren't encouraging. The only way I currently have | of making this work is for users to edit their GHC settings file to | point GHC at a version of gcc.exe from a newer MinGW (such as the one | which ships with Qt). The fact that this seems to work is encouraging, | but it's still a bit of a difficult process to put people through. | | I know that Windows developers are in short supply, so I would like to | offer what assistance I can in making this happen. There appear to be | copies of MinGW stored in the GHC repository at | http://git.haskell.org/ghc-tarballs.git/tree . Does the build system use | these automatically or are they just there for reference? | | Thanks, | | -- | Robin KAY | | _______________________________________________ | ghc-devs mailing list | [email protected] | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
