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