Re: [RFU] mingw-w64

[Charles Wilson <cygwin@cwilson.fastmail.fm>]

On 8/31/2011 5:48 AM, JonY wrote:
> On 8/31/2011 17:11, Corinna Vinschen wrote:
>> On Aug 31 15:15, JonY wrote:
>>> BTW, is GCC 4.6 for Cygwin anywhere near? :)
>> 
>> 4.5.3 is near, afaik.
> 
> OK, I was wondering how to transition 4.5.x to 4.6.x for mingw-w64
> when the time comes, pthreads-win32 will be removed in favor of
> winpthreads, they're not exactly ABI compatible. Right now, only
> libgomp is using pthreads-win32.

So, it sounds like mingw64's version of libgomp (for gcc-4.6) will
have to bump its DLL number from the current libgomp-1.dll to
libgomp-2.dll -- you don't want an existing -fopenmp client, that
links to both
	libgomp-1.dll (which itself depends on pthreadGC2.dll)
	pthreadGC2.dll
to suddenly get "surprised" by
	(new) libgomp-1.dll (which depends on winpthreads-0.dll)
	pthreadGC2.dll
because then that existing client would depend on two different
pthreads implementations.  That's a sure recipe for failure...

> C++ ABI for 4.6.x has also changed for mingw* (including mingw.org)
> with the introduction of thiscall, not sure if this will affect
> Cygwin itself.

Hmm. don't know what the correct (mingw[64]) solution for this would
be. In the past, when the C++ ABI changed, we didn't bump the
libstdc++ DLL number, because so many other things ALSO break (in
precompiled C++ clients), that just isolating ONE change via the DLL
number of one runtime lib was pointless.  I suspect that is true here,
too.

It probably means a "flag day" -- all precompiled mingw[org,64] C++
offerings will need to be simultaneously upgraded with the release of
the mingw[org,64] 4.6 compiler. (I don't think mingw.org HAS any,
so...non-issue).

OTOH, the cygwin project DOES provide several precompiled C++
packages, so cygwin will probably need to do a flag day for them (when
cygwin-gcc-4.6 is released), but I don't think the cygwin package
ITSELF would be affected.

-- 
Chuck