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
