This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc4: next release

On 7/7/2010 9:48 AM, Corinna Vinschen wrote:
On Jul 7 08:58, Christopher Faylor wrote:
On Wed, Jul 07, 2010 at 02:39:19PM +0200, Corinna Vinschen wrote:
Oh, and, talking about /opt or /usr, I'd prefer the above /usr/mingw*
sysroot idea.  However, I don't like the idea in the least to keep
two different versions of w32api around.  It's one target, so we should
have one set of headers only.  Right?  Wrong?  None of that?

Unfortunately, it sounds like we've stepped into the middle of a dispute between the mingw folks and the mingw64 folks.

Well, yes. But not one in which third parties like cygwin would take direct fire. And efforts are underway to enable closer cooperation, at least, between the two teams.

I don't think the projects will ever merge, and I think...that might be a good thing. The extra diversity -- so long as both teams continue to push fixes upstream -- should help make the gcc code better for PE/COFF all around, and that helps cygwin, too.

Maybe the best thing for
us to do would be to decide to use only one or the other but not both.

I think both teams would prefer if both toolchains were available on cygwin -- provided we @ cygwin have sufficient volunteers to handle the job(s). Is Dave K + JonY enough?

I know I would prefer to see both, and not have cygwin pick one or the other. More on that, in a different message.

Hmm, sounds bad.  I would love to have a 64 bit gcc in the distro.  From
my POV, the only reason not to use mingw64 would be, if the w32api has
been changed to 64 bit cleanness at the expense of 32 bit cleanness.

Well, there are three "parts" to the compiler and support packages (not counting binutils etc). Using the and cygwin names:

gcc itself

These are called, in mingw64 land,

   (contains the libs for both "mingw-runtime" and "w32api")
   (contains the include files for both "mingw runtime" and "w32api")

The mingw-runtime bits differ between the two projects as JonY has described elsewhere. The gcc bits for the two projects are all basically pushed upstream (there may be a few local patches, but those are probably minor). So, you just choose a different --target when building gcc and you can get mingw64 or version.

JonY also described how the w32api bits differ, from a technical standpoint. However, what JonY didn't mention was the w32api difference that actually was the root cause of the fork: licensing and provenance. (Later, personality issues widened the breach, and then technical decisions pushed things even farther apart. The personality issues, I hope, are on their way to being mended. Technical issues can be resolved. But the licensing...I dunno. And cygwin should probably care about that, *especially* with regards to the w32api headers and libs used to build cygwin itself).

Here's the deal, as I understand it:

(1) mingw32's (and cygwin's) w32api is under some custom license dreamed up by Anders Norlander, which is very MIT/X-ish, but isn't identical. And it is not, contrary to rumor, public domain. The mingw team is trying to contact Anders, to get that license revised to either (a) public domain, with a fallback to some other license in those jurisdictions that do not recognize public domain, or (b) actual MIT/X. But that's a side issue to this discussion (important, to be sure, but save that for later). For more info, see
and thread, as well as
and the subthread branching off of that message.

(2) mingw32's (and cygwin's) mingw-runtime is public domain. This may be problematic in some jurisdictions (especially some EU countries) that do not recognized pd -- which is one reason the 'relicensing' discussion came up and is on-going.

(3) Now, given these issues, especially the pd "problem", mingw64's crt+headers (which combine and extend elements that fall under cygwin's w32api AND mingw-runtime categories), are provided under an EITHER/OR arrangement: according to the lawyers at Kai's company who looked in to this, the licensing/disclaimer text boils down to: copyright is disclaimed and it is public domain, UNLESS the legal jurisdiction doesn't recognize the concept -- in which case copyright is asserted and the files are available under the ZPL (a very permissive, non-copyleft but GPL-compatible license).

I don't *really* understand how all that works, 'cause IANAL,'s all kosher according to Kai's legal beagles. And, given all that, then (IM-not-a-laywer-O) can freely snarf, under public domain, anything in mingw64 so long as they do so in a jurisdiction that recognizes such -- there's no legal impediment to incorporating a lot of mingw64's stuff. is confident that the contents of mingw64 truly ARE legally public domain. And that's the rub, and the root of the original conflict:

(4) In order to preserve the ability of to release updates to w32api under any copyright-based license -- such as Ander's homegrown "license", a new MIT/X license, or even disclaimed as public domain -- the team believes that ALL such contributions must come from totally open, public sources.

Such as msdn documentation.

They require that all contributions to w32api be so documented, as coming from such-and-such a page at msdn. Unfortunately, not everything in MS's w32api is publicly documented. And the EULA of the Windows SDK includes stuff like prohibitions against reverse engineering, copyright and specific non-redistribution license terms on the headers, etc.

The big fear, back when Kai & co were originally working on the 64bit support, was that their changes had been derived from non-public sources. At the time, Kai presented his initial 64bit support as a single massive patchdump, and asked for it to be merged into Danny said no, please break it down into smaller, easily reviewed pieces, AND document where all changes to the w32api and mingw-runtime bits came from: what msdn page, etc.

Kai refused (or couldn't, or didn't have time, or ???), and was born. Then feelings got bent, and things went downhill on both sides.

IIUC, mingw64 now has a policy where new contributions are developed in a clean-room setting: some people may look at the Windows SDK and document what they find, and then DIFFERENT people can use that documentation to develop patches for mingw64's w32api stuff.

Is this procedure always followed? How long has it been in place? Where did the contributions that predate that arrangement come from? And even if EVERY single piece of mingw64 is fully "covered" by this clean room development technique -- is that sufficient to allow to accept those changes en masse?

Or does need to

(a) painstakingly document each and every w32api change in, whether from msdn or clean-room, and determine individually whether each piece can be added to's w32api

(b) or, change its own policy to match mingw64's and simply adopt any and all patches derived from their work,

(c) or, work with a CoApp guy (MS employee) who has recently expressed (official?) interest in working with mingw32. The idea was to try to get at least some of the core Windows SDK headers released under a less restrictive license. (Pigs can fly, if you strap a rocket pack on their back...) Then, wouldn't care where mingw64 got its w32api stuff; they could expropriate directly from mingw64's headers or directly from the newly freed Windows SDK ones.

In any event and regardless of licensing concerns, unless completely drops winsup/mingw and winsup/w32api in favor of mingw64's crt/headers, you'd still need to do a lot of work because mingw64's code arrangement differs from's -- it's not a simple cut-n-paste to import mingw64 stuff into And who is going to do that work? Chris Sutcliff expressed interest in pursing option (a) a few months ago, but it is a daunting task and AFAIK little progress has been made.

So...where does cygwin fall in this discussion concerning the provenance of w32api data?

It came up in one of those discussions @ mingw that what they really need is actual legal advice. But, has no independent legal existence and no access to legal services. It was mentioned that perhaps Red Hat, given that they have a vested interest in all this, what with cygwin's reliance on the w32api stuff "from", might be able to obtain legal advice for on this issue. As well as on the discussion concerning relicensing w32api, and possibly mingw-runtime, under MIT/X (or whatever) rather than public domain.

But I certainly won't interfere in a dispute between two communities
I'm not part of.

I think "picking sides" by choosing one or the other would put us in greater danger of "interfering in [that] dispute" than simply providing both, and letting our users choose.

However, with regards to what version of the w32api headers and libs *cygwin's own compiler* uses...I think cygwin has no choice but to pick a side, given the licensing issues involved: "our" w32api package would be either, or mingw64 based. And that needs legal advice from Red Hat *for cygwin*, if not for **.

But...that has no bearing on which mingw32-target cross compiler we provide, since cygwin itself is built using the cygwin compiler.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]