On 8 November 2011 12:30, Jose Fonseca <<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> At the moment MSVC build's failing with the error mesa.lib(uniform_query.obj) : error LNK2001: unresolved external symbol "int MESA_VERBOSE" (?MESA_VERBOSE@@3HA) build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll : fatal error LNK1120: 1 unresolved externals and trying to fix seems a to be deep rat hole. Clearly extern "C" is missing, but what surprises me is that this works on Linux. One problem is that putting enclose #includes inside extern "C, like: extern "C" { #include "foo.h" } is non portable, because "foo.h" may include system headers, some of which often have #ifdef __cplusplus // Helper C++ class class Foo { }; #endif /* __cplusplus */ and C++ code inside extern "C" is an error. That is, all our .h headers that will also be included by .C++ files should follow the following pattern: // includes (but no declarations) #include <boo.h> #include "foo.h" .... #ifdef __cplusplus extern "C" { #endif // type/function declarations here (but no includes!) struct aaa; typedef int bbb; ... #ifdef __cplusplus } #endif Second, it would really help to clearly distinguish headers that are meant to be used exclusive by C++ with a different suffix (e.g., .hpp). And leave .h for headers that are meant for joint C/C++ consuption. Take e.g., ../glsl/program.h, are these supposed to be C functions or C++ functions? There's no way to tell just from reading the headers. So it's not clear if those type/functions should be inside extern "C" {..} or not. Is this OK? Another approach that would avoid all these extern "C" would be to all Mesa source files to .cpp. A part of a few reserver symbols and type strictness, C is a subset of C++. But this would probably be even more disruptive than adding extern "C" ... </blockquote><div> A (closed-source) project I worked on in the past had very good luck with a similar approach to this, however to avoid disruption in the code base, rather than change all of the .c files to .cpp, we simply changed the makefiles so that all source files were built as C++. It might be worth a try here to ease the transition. </div></div>