----- Original Message ----- > On 11/08/2011 12:30 PM, Jose Fonseca wrote: > > 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 > > That is completely correct. We've been really sloppy about that up > to > this point. I've been trying to clean some of that up as it gets in > my way.
Thanks. I'll do the same. > > 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. > > The problem with .hpp is that sometimes we change our mind. Previous > to > a recent patch series, glsl_types.h was C++ only. It is now included > in > C files as well. We can always rename them back, but .h/.hpp is a lesser issue: as long as the extern "C" are there then it becomes evident what language (and name manling) is to be expected. > > 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" ... > > The problem is that all of the DRI drivers use C99 features that are > not > part of C++. Yes, I think that standardizing on C++ makes sense on the long term (due to GLSL, LLVM, and general productivity), but a naive rename will be a can of worms. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev