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
On 6/10/2014 03:46, Robin KAY wrote:
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,
My experience is as follows: 1. 64-bit GHC uses mingw-w64 runtime/toolchain. Mingw-64 runtime and binutils may be upgraded to the most recent versions and gcc may be upgraded to versions up to 4.8.x. Gcc 4.9 is incompatible with GHC's runtime linker now. Btw, did anybody try GHC + gcc 4.9 on linux? 2. 32-bit GHC uses mingw runtime/toolchain. I didn't try to upgrade it for a long time but I think it shall succeed too (latest mingw gcc is 4.8.1). Btw, mingw runtime/toolchain development is stalled and it lags behind mingw-w64 *considerably*. It is possible to use 32-bit mingw-w64 runtime/toolchain with GHC, but it requires some patches to be made. I have such a patchset ready and can provide it if GHC HQ decide to switch 32-bit GHC distribution to mingw-w64 runtime/toolchain. It is also important using mingw-w64 opens the door to *plenty* of prebuilt packages available through Msys2 project, see http://sourceforge.net/projects/msys2/files/REPOS/MINGW. Cheers, Kyra
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:ghc-devs-bounces@haskell.org] On Behalf Of Robin | KAY | Sent: 10 June 2014 00:46 | To: ghc-devs@haskell.org | 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 | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs
Hello Simon, On 2014-06-10 at 10:25:46 +0200, Simon Peyton Jones wrote: [...]
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.
Btw, there's just one thing I'm worried about with keeping those large MinGW binary tarballs in a Git repo: The Git repo will grow monotonically with each new compressed .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to detect shared bitstreams. So effectively each MiB of binary-data added will effectively grow the Git repo everyone will have to clone (even if only the latest MinGW for a specific 32/64-bit platform is desired) by that same amount. Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. Can't we simply put the tarballs in a plain HTTP folder on http://ghc.haskell.org, and store a list (or rather a shell script) of URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? Cheers, hvr
Btw, there's just one thing I'm worried about with keeping those large MinGW binary tarballs in a Git repo:
The Git repo will grow monotonically with each new compressed .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to detect shared bitstreams. So effectively each MiB of binary-data added will effectively grow the Git repo everyone will have to clone (even if only the latest MinGW for a specific 32/64-bit platform is desired) by that same amount.
Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB.
Can't we simply put the tarballs in a plain HTTP folder on http://ghc.haskell.org, and store a list (or rather a shell script) of URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? I agree with this. Having binaries in git is really dirty for several reasons. It would be cleaner to retrieve src and build it through the build system. But I suspect Windows people don't commonly do this(?), so checking for the binaries, and if they're not found, downloading
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 10/06/14 10:42, Herbert Valerio Riedel wrote: them (or asking the user to fix their paths) would likely suffice. The binaries should in any event not be in git... And as hvr points out, tarballs are a mess by themselves regardless of whether they contain binaries or source, because git (rightly) thinks they are blobs. Apologies for any assumptions made in this email that don't hold true - -- I do not use Windows. - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOW0e8ACgkQRtClrXBQc7WzFAD9Fcz+Ur80Dh2wCqrZxGYEABEC QetdlxKC49nCPfLRfwwA/0e4PdVDv6+af7eeHFmUKXf5nDjxPx8ex3i+PpWC/xgL =tE6K -----END PGP SIGNATURE-----
| Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. | | Can't we simply put the tarballs in a plain HTTP folder on | http://ghc.haskell.org, and store a list (or rather a shell script) of | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? Personally I'm fine with that, if someone feels able to implement it (and document in the wiki:Repositories page). But remember that I'm not very au fait with all the issues so I defer to others Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 10 June 2014 09:43 | To: Simon Peyton Jones | Cc: Robin KAY; ghc-devs@haskell.org | Subject: Re: GHC MinGW distribution | | Hello Simon, | | On 2014-06-10 at 10:25:46 +0200, Simon Peyton Jones wrote: | | [...] | | > 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. | | Btw, there's just one thing I'm worried about with keeping those large | MinGW binary tarballs in a Git repo: | | The Git repo will grow monotonically with each new compressed | .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to detect | shared bitstreams. So effectively each MiB of binary-data added will | effectively grow the Git repo everyone will have to clone (even if only | the latest MinGW for a specific 32/64-bit platform is desired) by that | same amount. | | Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. | | Can't we simply put the tarballs in a plain HTTP folder on | http://ghc.haskell.org, and store a list (or rather a shell script) of | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? | | Cheers, | hvr
git-annex (written in Haskell!) is designed specifically for this purpose.
might be worth a look.
-E
On Tue, Jun 10, 2014 at 4:02 PM, Simon Peyton Jones
| Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. | | Can't we simply put the tarballs in a plain HTTP folder on | http://ghc.haskell.org, and store a list (or rather a shell script) of | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand?
Personally I'm fine with that, if someone feels able to implement it (and document in the wiki:Repositories page).
But remember that I'm not very au fait with all the issues so I defer to others
Simon
| -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 10 June 2014 09:43 | To: Simon Peyton Jones | Cc: Robin KAY; ghc-devs@haskell.org | Subject: Re: GHC MinGW distribution | | Hello Simon, | | On 2014-06-10 at 10:25:46 +0200, Simon Peyton Jones wrote: | | [...] | | > 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. | | Btw, there's just one thing I'm worried about with keeping those large | MinGW binary tarballs in a Git repo: | | The Git repo will grow monotonically with each new compressed | .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to detect | shared bitstreams. So effectively each MiB of binary-data added will | effectively grow the Git repo everyone will have to clone (even if only | the latest MinGW for a specific 32/64-bit platform is desired) by that | same amount. | | Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB. | | Can't we simply put the tarballs in a plain HTTP folder on | http://ghc.haskell.org, and store a list (or rather a shell script) of | URLs+checksums in ghc.git to retrieve the tarballs if needed on demand? | | Cheers, | hvr _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Dear Simon et al., On 10/06/14 09:25, Simon Peyton Jones wrote: [snip]
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. Thanks for your encouragement. I hope to have some time to start working on this shortly and have created ticket #9218 [1] to track my progress.
[1] https://ghc.haskell.org/trac/ghc/ticket/9218 Regards, -- Robin KAY
Robin,
Thanks a lot. This has been on my TODO list for a while, but it's been
low priority. I'd love to see a more modern MinGW tools (it will
surely come with many bugfixes), and I know many windows users would
agree. Do let us know if something comes up.
On Wed, Jun 18, 2014 at 6:27 PM, Robin KAY
Dear Simon et al.,
On 10/06/14 09:25, Simon Peyton Jones wrote: [snip]
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.
Thanks for your encouragement. I hope to have some time to start working on this shortly and have created ticket #9218 [1] to track my progress.
[1] https://ghc.haskell.org/trac/ghc/ticket/9218
Regards,
-- Robin KAY
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (7)
-
Alexander Berntsen -
Austin Seipp -
Edsko de Vries -
Herbert Valerio Riedel -
kyra -
Robin KAY -
Simon Peyton Jones