OK.  I found a way to make it easier to trap this sort of issues going forward, 
regardless of compiler. See patch I just posted.

Jose

________________________________________
From: Brian Paul <bri...@vmware.com>
Sent: 11 December 2014 22:05
To: mesa-dev@lists.freedesktop.org
Cc: Jose Fonseca
Subject: Re: [Mesa-dev] `extern "C" { #include "foo.h" }`  is evil

On 12/11/2014 02:32 PM, Jose Fonseca wrote:
>
> Including system's headers inside extern "C" { ... } is not safe, as system 
> headers may have C++ code in them, and C++ code inside extern "C"  { .. } 
> doesn't work.
>
> This is because putting code inside extern "C" won't make __plusplus define 
> go away, that is, the headers being included thinks is free to use C++ as it 
> sees fits.
>
> Including non-system headers inside extern "C"  is not safe either, because 
> non-system headers end up including system headers, hence fall in the above 
> case too.
>
> Conclusion, includes inside extern "C" is simply not portable.
>
>
> I said this before, but I failed to keep a close watch on this.  And the 
> unfortunate thing is that sometimes things "appear" to work when the above 
> rule is not observed, but it's enough to switch to slightly different SDKs / 
> standard libraries and build fails miserably...
>
> Yes this happens with MSVC headers which often have C++ on some places, but 
> it could happen with any other OS really.
>
>
> Please help do the right thing here, which is add extern "C" to headers 
> themselves that need to be included from C++ source files.  Thanks.

In particular, the #include "util/u_atomic.h" in glsl_parser_extras.cpp
is causing us grief with some versions of MSVC.

I've reverted 9db278d0e2b3bf35b28f00ab7ec3392443aae6b3 locally for now.
  I'll see if I can work on a proper fix for this tomorrow.

-Brian

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to