Wine and C99 inline incompatibility

[Zephiris]

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