[Releasing] MinGW 4.8.1 upgrade for 5.2 - InterlockedCompareExchange conflict

[Koehne Kai]

> -----Original Message-----
> Subject: Re: [Releasing] MinGW 4.8.1 upgrade for 5.2 -
> InterlockedCompareExchange conflict
> 
> On terça-feira, 3 de setembro de 2013 12:25:14, Koehne Kai wrote:
> > It looks like one cannot run the current Qt 5.1.0 , Qt 5.1.1 MinGW
> > that was built with mingw-builds 4.8.0 rev2 on top of a newer gcc
> > 4.8.1 runtime. The reason is an 'InterlockedCompareExchange at 12' symbol
> > that apparently was accidentally part of the toolchain [1], and which
> > at least some ICU / Qt libs now require.
> 
> Sorry, after reading the full thread again in the mingw ML, I'm confused. The
> reports in the mingw ML are that the libraries would export an extra symbol
> that should not have been exported.
> 
> Is that correct: an *export* from the DLL? Not an *import* from another DLL
> (kernel32.dll or a mingw DLL)?

With [1], the symbol(s) are indeed _exported_ from libstdc++-6.dll, and _imported_ by most Qt libs, with one notable exception: icudt51.dll actually exports the symbols, too.

> 
> I have a fairly recent build of Qt 5.2 with the toolchain at [1]. It shows me
> this:
> 
> $ for f in *.dll; do objdump -p $f | grep -B2 Interlocked; done
>         DLL Name: libstdc++-6.dll
>         vma:  Hint/Ord Member-Name Bound-To
>         e6b4        0  InterlockedCompareExchange at 12
>         DLL Name: libstdc++-6.dll
>         vma:  Hint/Ord Member-Name Bound-To
>         106cc       0  InterlockedCompareExchange at 12
> [and others]
> 
> That means it's an *import* of the symbol, from libstdc++. So, IIUC, there
> was
> a problem with the headers, causing the symbol to get exported from some
> libs,
> including and especially the libstdc++ that got shipped with that release.
> 
> Then, for some reason, code used InterlockedCompareExchange, which the
> mingw
> headers had as a regular function as opposed to a
>  static inline
> __attribute__((__always_inline__,__gnu_inline__,__artificial__))
> intrinsic (see GCC's *intrin.h files). That meant our DLLs now import the
> symbol from libstdc++.
> 
> My suggestion for resolution: don't break BC. Keep the symbol exported
> from
> the MinGW libraries where it got exported. From what I can tell, it's
> libgomp-1.dll, libquadmath-0.dll, libssp-0.dll and libstdc++-6.dll.

I guess that would be a request to the general Mingw-w64 mailing list then ... Personally, I'm afraid breakages like things like this are the price for Mingw-w64 being a ' rolling release', where mingw-builds just uses latest trunk. 

My 2 cents

Kai