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.