gcc4: next release

[Charles Wilson]

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 mingw.org and cygwin names:

gcc itself
w32api
mingw-runtime

These are called, in mingw64 land,

gcc
crt
    (contains the libs for both "mingw-runtime" and "w32api")
headers
    (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 mingw.org 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
   http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3985
and thread, as well as
   http://thread.gmane.org/gmane.comp.gnu.mingw.user/33519/focus=33537
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, but...it's 
all kosher according to Kai's legal beagles.  And, given all that, then 
(IM-not-a-laywer-O) mingw.org 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 mingw.org 
incorporating a lot of mingw64's stuff.

IF...mingw.org 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 mingw.org 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 mingw.org 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 mingw.org. 
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 
mingw64.sf.org 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 mingw.org to accept 
those changes en masse?

Or does mingw.org need to

(a) painstakingly document each and every w32api change in mingw64.org, 
whether from msdn or clean-room, and determine individually whether each 
piece can be added to mingw.org'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 mingw.org 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, mingw.org 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 mingw.org 
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 mingw.org's -- it's not a simple cut-n-paste to 
import mingw64 stuff into mingw.org.  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, mingw.org 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" mingw.org, might 
be able to obtain legal advice for mingw.org 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 mingw.org-based, or mingw64 based.  And that needs legal 
advice from Red Hat *for cygwin*, if not for *mingw.org*.

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

--
Chuck