From: Earnie B. <ea...@us...> - 2012-04-18 18:19:15
|
FYI https://sourceforge.net/projects/mingwbuilds/ http://code.google.com/p/mingw-builds/ Primarily providing mingw-64 builds of GCC. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: waterlan <wat...@xs...> - 2012-04-19 07:29:14
|
On 2012-04-18 20:19, Earnie Boyd wrote: > FYI > > https://sourceforge.net/projects/mingwbuilds/ > http://code.google.com/p/mingw-builds/ > > Primarily providing mingw-64 builds of GCC. Win64 is getting pretty common now. Perhaps it is time again to consider combining efforts with the mingw-w64 project. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Earnie B. <ea...@us...> - 2012-04-19 12:39:52
|
On Thu, Apr 19, 2012 at 3:28 AM, waterlan <wat...@xs...> wrote: > On 2012-04-18 20:19, Earnie Boyd wrote: > >> FYI >> >> https://sourceforge.net/projects/mingwbuilds/ >> http://code.google.com/p/mingw-builds/ >> >> Primarily providing mingw-64 builds of GCC. > > > Win64 is getting pretty common now. Perhaps it is time again to > consider combining efforts with the mingw-w64 project. I would rather consider patches to winsup/mingw and winsup/w32api, maybe even creating winsup/w64api. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Charles W. <cwi...@us...> - 2012-04-19 13:57:39
|
On 4/19/2012 8:39 AM, Earnie Boyd wrote: >> Win64 is getting pretty common now. Perhaps it is time again to >> consider combining efforts with the mingw-w64 project. > > I would rather consider patches to winsup/mingw and winsup/w32api, > maybe even creating winsup/w64api. As you (Earnie) are probably aware, but the rest of this list might not be, the cygwin folks are already looking at switching to use mingw64's w*api headers in their tentative planning for cygwin64. >From that discussion, it was pointed out that there is *NO* reason to separate "w32api" libs, src, and headers from "w64api" libs, src, and headers -- at least, at the source level (sure, the .a's will be different and need to go into different places -- different $build triple? x86_64-pc-mingw32?). The WinSDK doesn't seem to need to separate their 64bit and 32bit sources; the mingw64 folks don't seem to need that; why should we needlessly complicate our implementation, when we have two independent demonstrations that such is not necessary? Sadly, I think we need to (restart) the discussion we had previously about the licensing issues vis. mingw.org vs mingw64's policies. Something was brought to my attention in that regards; I'll PM the necessary parties in a few days. Licensing issues aside, IMO mingw64's w*api headers/libs are superior to ours. Their runtime library support (e.g. libmingwex, startup objects, etc), AFAIK, differs only cosmetically from ours, although I'm not sure about the status of long double support or C99 functions in either of them. The key bit is organization: their runtime lib support is co-mingles with their w*api stuff, so it's hard to "just use mingw64's w*api" without also pulling in their libmingw-related libs and headers. -- Chuck |
From: Chris S. <ir0...@gm...> - 2012-04-19 17:32:06
|
On 19 April 2012 09:56, Charles Wilson wrote: > Licensing issues aside, IMO mingw64's w*api headers/libs are superior to > ours. Their runtime library support (e.g. libmingwex, startup objects, > etc), AFAIK, differs only cosmetically from ours, although I'm not sure > about the status of long double support or C99 functions in either of > them. The key bit is organization: their runtime lib support is > co-mingles with their w*api stuff, so it's hard to "just use mingw64's > w*api" without also pulling in their libmingw-related libs and headers. I agree with Chuck, their w*api is a lot more feature complete then our w32api. They have a more active group of contributors to their w*api and have more than 1 person committing the changes. Unfortunately these days I'm finding it hard to find cycles to commit patches (never mind developing patches) to the w*api and mingwrt. If we decide to not merge the development effort, then I'd be greatful if someone would be willing to step up to help out with / take over maintaining the w32api and mingwrt rather then having these packages suffer as a result of my lack of time. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |