I haven't seen this addressed and couldn't get an answer out of anyone on IRC. GCC defines 'extern inline' very differently from other compilers and C99. inline isn't actually guaranteed to inline (obviously), but 'extern inline' on GCC never defines a global function. References to the function are either inlined, or passed to another global function.
In definition blocks that include things like InterlockedExchange, GCC's behavior of extern inline is relied on heavily, specifically that it'll (effectively) never conflict with another definition, and never define a symbol.
Specifically, this appears to conflict with, say, when InterlockedExchange is actually defined later in the source file. Even if 'extern inline' is replaced by 'static inline', that's a problem. For that particular case, for instance, I tried to work around by only exporting separate extern declaration if _KERNEL32_ is defined, otherwise define the static inline part, since InterlockedExchange needs to be exported. But not so amusingly, the tools (loader, programs, etc) don't export __WINESRC__, so can't bring in the inlined definitions. I'm not quite sure how the GCC version of thing gets around that, as the extern inline versions aren't exported, and the tools don't depend on -kernel32.
There are, of course, a few ways to get around that. Either #if __STDC_VERSION__ >= 199901L has to be used (which would entail all compilers going for specific C99 compliance only apparently), or compiler-specific blocks, or both, but it appears as if either __WINESRC_ needs to be defined for tools/server/etc as well, or they need to depend on kernel32, with no inline blocks defined for these things.
There are a few other GCC-isms used that are incompatible with basically everything else, but this appears to be the great big ugly one. If I've missed something, or there's another option, let me know, but it's been nasty trying to work around this one at all, since trying to simply forcibly define __WINESRC__ for the rest would probably doom any patch.
And before anyone asks, part of the reason this is coming up is because GCC apparently doesn't produce the most debuggable code on Solaris. But besides that, less explicit dependence on GCC for things where there's no functional difference would be a good thing, no? ^^;
[ Reference: http://blogs.sun.com/x86be/entry/gcc_style_asm_inlining_support http://www.greenend.org.uk/rjk/2003/03/inline.html http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Inline... ]