Hi,
I’ve just rebuilt a 1.8 version from the CVS repository and I’m now seing the following kind of link error on a previously working panda c++ appli.
error LNK2001: unresolved external symbol "private: static class TypeHandle GeomVertexData::CacheEntry::_type_handle" (?_type_handle@CacheEntry@GeomVertexData@@0VTypeHandle@@
Don’t have a clue where this may come from. So is there a way to a quick turn-around?
BTW. I’m too seing another behaviour not experienced before, ie: for a strange reason some headers are being fetched in /parser_inc directory… and are screwing up the compile. This is easily fixed by removing this directory… (ugly way to solve this I admit!)
That symbol appears in geomVertexData.cxx, which gets compiled into libpanda.dll. So if you’re linking with libpanda.lib you should have that symbol available.
Are you getting this compilation error when you build Panda itself, or when you build your own application?
Fetching headers from parser-inc is indeed a serious problem. Again, are you getting this problem when you build Panda itself, or when you build your own application? If it’s a problem when you’re building your own application, make sure you do not have this directory on your include path.
(2)I don’t have C:\Panda3D-1.8\include\parser-inc on path
but I do have C:\Panda3D-1.8\python\include since at a certain point I include dtoolbase.h which needs pyconfig.h…
Oh, I see, in my code I should then make sure that I have #undef HAVE_PYTHON
which I can’t remember to have needed in the past months…
Ah, I see what’s going on with the CacheEntry symbol–we must have new reference in the .I file, which requires the symbol to be exported from the DLL, whereas it wasn’t required before. I’ve just committed the required change; please pick up the latest code and try it again.
I don’t understand what’s going on with the parser-inc thing, though. Tell me more. You shouldn’t have to #undef HAVE_PYTHON. If you are compiling with Python, then doing so could cause other problems; and if you are not compiling with Python, then this symbol shouldn’t be defined in the first place. (Are you compiling with Python?) What is it that you solved, specifically, by undefining this symbol, and what led you to discover that you could solve it this way?
Related to parse_inc, I just checked even with predefining: #undef HAVE_PYTHON
I’m still getting the compiler trying to fetch stuff from parser_inc directory (and obviously screwing up the built) :
include\parser-inc\stdtypedefs.h(25): error: invalid redeclaration of type name "off_t" (declared at line 479 of "c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\wchar.h")
and so on...
I don’t understand (besides having panda1.8/python/include in my path) what’s going on here.
BTW. the only (quick) fix so far is to remove the parser_inc directory… which I didn’t have to do previously…
I have got a new version of panda last night and compiled a debug and release build. I’ve compiled with --no-python and everything has gone through fine. Don’t know if that is of any help.
So adding panda1.8/python/include in the include path, then causes panda1.8/include/parse-inc to be fetched if this directory exists (back to square 1),
this may come from HAVE_PYTHON being defined somewhere… (I don’t have clue where and why !!!)
Bottom line: for the time being I keep with the turn around of removing parse-inc …
Huh? How does this happen? Adding python/include also causes parser-inc to be added? Why? That doesn’t make any sense at all. These are two different directories, and nothing in Python knows anything at all about interrogate’s parser-inc directory. Anyway, there’s no way that including another file can cause parser-inc to be added to the include path, unless you’re suggesting there’s a weird bug in Visual Studio.
HAVE_PYTHON is a symbol defined within dtool_config.h to tell the Panda code whether it is being built against Python or not. It’s important not to mess with it. It should be defined when you are compiling with the Python interfaces, as it appears that you are. However, all this does is cause additional Python symbols to be included and additional Python interfaces to be compiled; it does not add parser-inc to the include path.
I think there must be a parser-inc somewhere in your project specifications that you’re not aware of. I can’t think of any other way it could be getting onto the include path.
Hi,
I understand it’s weird but the exact wording was:
adding panda1.8/python/include in the include path, causes ((ie indirectly) panda1.8/include/parse-inc headers files to be fetched if this directory exists (back to square 1)
Anyway, I agree that all this is strange and I don’t know how this parse-inc is entering into the game…
I can’t see where it can come from besides including another header file that may then have it called as a side effect…
Ok, for the time being I stick with my turn around.
But there’s no way a header file can “call” in a whole directory and add it to the include path. At the best, a header file might explicitly include a file from parser-inc by doing something like:
#include "parser-inc/stupidfile.h"
but there’s no code in Panda that does this, nor would anyone have a reason to write such a thing. And even if there were such a thing, you would get an error on that line when you tried to compile after removing the parser-inc directory.
Can you create a sample project that demonstrates the parser-inc getting mysteriously added?
What I’ve just done is to use the well known ralph c++ project
in the include path I just have “C:\Panda3D-1.8.0\include”
When the compile starts it gives:
1>ralph.cxx
1>c:\panda3d-1.8.0\include\dtoolbase.h(109) : fatal error C1083: Cannot open include file: 'pyconfig.h': No such file or directory
1>Build log was saved at "file://c:\Users\jc\Desktop\PANDA_BUILD_BOT\Roaming-Ralph-CXX\Release\BuildLog.htm"
1>ralph - 1 error(s), 1 warning(s)
So I suppose HAVE_PYTHON is being set-up somewhere (actually in dtool_config.h : #define HAVE_PYTHON 1)
[b]
2 side remarks:
At this point I really don’t need any python since my target is c++. (so I don’t really see the point of pyconfig.h beeing called as include…
More generally I really don’t understand the need to have C:\Panda3D-1.8.0\python\libs required and get python.dll link to a mere panda C++ app!?
Why would python be involved with a panda c++ code?[/b]
so, back to ralph, if I want the compile to go on I add “C:\Panda3D-1.8.0\python\include” to the list of include directories.
and if parser-inc exists under directory C:\Panda3D-1.8.0\include I’m back to the issue!!!
OK, everything you describe here is actually exactly what I would expect.
HAVE_PYTHON is defined within dtool_config.h, because this version of Panda (as distributed on this site for download) was, in fact, built with Python, and therefore it has Python hooks already compiled within it. It is necessary for HAVE_PYTHON to continue to be defined when any application links with this version of Panda, in order to guarantee that the binaries match correctly. (You might be able to undefine HAVE_PYTHON and find the resulting program actually runs without crashing. You might also be able to drop a lit match into a barrel of gasoline and not blow up. I’m not recommending either action.)
You don’t actually need to link with python/libs and get python.dll, however. You could instead simply add libp3pystub.lib to your list of libraries. This library stubs out the require Python interfaces so your program can run without python.dll.
But still, this has nothing to do with your reported problem. You report that adding python\include to your include path also adds parser-inc somehow. I don’t see how; and I’m not sure how you concluded that python is related.
But, you’ve given me a sample project: you tell me that the Roaming Ralph project demonstrates this problem. Can you give me a link to this project? I don’t have a win32 machine with me at the moment, but I can try it tomorrow.
By the way, are you sure that you don’t have parser-inc on your INCLUDES environment variable or something like that?
Well at this point, I really do think something is seriously flawed somewhere in my install, since I agree all seems to behave as if include/parser-inc was in the include (this obviously was my first check: it is not neither in project include or in default vs2008 settings !!)
Instead of scratching anylonger my head, what I’m going to do is to reinstall/repair vs2008 (maybe there is something wrong there)
btw. I noticed too that 1.8.0 uses python 2.7.2 so I’ll make sure at the same time I’m using an updated 3rd party libs.
Since what I’ve been doing in the past is merely to recompile a cvs with former 3rd party, and then drop the build directory into the c:panda-1.x.x directory, it could well be that there is some mismatch somewhere. So let me start with a fresh complete build.
NB. Related to having python/libs in the path, here is what happens if I don’t have it (even if I have listed libp3pystub.lib) :
1>Linking... (Intel C++ Environment)
1>ipo: remark #11081: Cannot open library python27.lib from #pragma comment
don’t know where this pragma comes from…
btw. side question, just for my understanding: why python should be involved at all while compiling/linking a simple c++ panda app ?
After a complete cleanup of Panda installed libraries, removing Panda Game, get rid of python 2.6.6 and completing a repair of VS2008 ->> things are back to normal and this ugly '#&@@!! include parse-inc phenomenon has disappeared.
Still don’t know what was going on but believe me it has been a nightmare!
Thanks a lot for your support, and sorry for bringing up this crazy riddle
[i]PS. For my education only : Still related to having python/libs in the lib path, here is what happens if I don’t have it (even if I have listed libp3pystub.lib) :
1>Linking… (Intel C++ Environment)
1>ipo: remark #11081: Cannot open library python27.lib from #pragma comment
don’t know where this pragma comes from…
so again: why python stuff should be involved at all while compiling/linking a simple c++ panda app ?[/i]
Hmm, and that’s coming from Python itself, it adds a #pragma to tell the compiler to bring in python27.lib. Hmm, strange, though, that I haven’t seen this happen to my own code before–I’d assumed that the #pragma in question doesn’t get pulled in unless you are actually compiling Python code. I’ll investigate this a bit more closely.
It’s because the version of Panda is linked with Python, so you have to satisfy those dependencies. If you built a version of Panda that wasn’t linked with Python (e.g. with --no-python on the makepanda command line), then you wouldn’t need to provide Python in your own project either.
