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.
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.
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++.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
