Re: [RFU] mingw-w64

[JonY <jon_y at users dot sourceforge dot net>]

On 8/31/2011 21:54, Charles Wilson wrote:
> 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...
> 

Ideally, libgomp should provide proper ABI/API isolation from whatever
underlying thread implementation, so a bump on libgomp shouldn't be
necessary, but I have yet to test this.

Reading the package contributor's guide, there isn't a way to force a
mutually exclusive package, eg old pthreads-win32 with devlibs musn't be
installed with winpthreads.

>> 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.
> 

Not bumping the number would also be problematic for precompiled code
using the old ABI, I was thinking the old dll be made available via
mingw32-libstdc++-6-compat-1 DLL only package.

Of course, talk is easy, implementing it would be another problem, since
libstdc++ is so integrated into GCC.

Attachment: signature.asc
Description: OpenPGP digital signature