Due to the recent commit by drwr mentioned here I’ve downloaded Panda3D from CVS and rebuilt it using MSVC 2005. When I did this I ran into a few issues, which I think deserve mentioning:
Python and MSVC appear to cause a DLL name conflict with two different DLLs both named “dbi.dll”. I’m not entirely sure about this since I didn’t delve very deep into it, so it may be something else I’ve messed up in my own system. In any case the problem causes cl.exe to spew fatal error messages about a program debug database manager version mismatch.
Removing any compile flags that refer to debug database generation (ie. /Zi and /Fd) seems to fix the problem. I was unsuccessful when trying to achieve this in the .sln file provided for ppremake, and I don’t have autoconf in my Cygwin, so I went with makepanda.bat. The debug flags to be removed can be found in makepanda.py.
It is not obvious from the web pages (at least not where I looked) how to merge the CVS modules into a proper build tree; lots of trial and error fixed this. It seems that any CVS module that contains a file named “Package.pp” needs to be a subfolder of the build root named the same as the CVS module, while anything else should be merged directly into the build root. One could probably write a script that fetches the CVS modules and sets up the build tree properly.
In order to complete the build tree, one needs to download the “samples” and “third party tools” packages. These should be unpacked such that the “samples” and “thirdparty” directories are subdirectories of the build root. The download page does not mention nor link to information about this where the CVS repository is linked, so it took me a couple of annoying extra turns of research and downloading to get the compile started.
“libpgraphnodes” was not listed in makepanda.py. I had to add various lines to get that built properly (this caused the header files from that library to be missing in the “built” tree, so the first symptom was the compiler reporting a lot of missing header files related to lighting). Looking at eg. “libpgraph” for examples helped.
Revision 1.12 of the file panda/src/events/pythonTask.cxx introduces a dependency to Dtool_PythonTask, which cannot be found anywhere (not even on Google; imagine that). Reverting this “memory leak fix” resolved the compile process, but I suppose this means I now have some memory leaks in that build of Panda3D.
The directx sdk version I have installed (February 2006) does not include the header/lib files for the web cam support used by Panda3D. Not sure whether it’s been deprecated or added after Feb 2006, but it might be worth looking into. Adding --no-directcam to the makepanda command line fixed this.
I hope this will be of help to some people trying to compile the CVS tree (and with some luck someone will see this and either check in or post information about whatever is missing so that Dtool_PythonTask can be made available for linking).
I’ve never heard of this problem before. We build every day with debug symbols enabled, we have done so for many years, and don’t have any problems with this.
Maybe this is a compiler version conflict? I don’t think MSVC2005 and MSVC2008 are compatible, and if Python was compiled with 2008 you might have troubles. I’m not sure, but I think all of the thirdparty tools available here may have been compiled with 2008. But I’m not the authority on this, and there may not be a version conflict at all.
Isn’t it just check out from the root, move in the thirdparty tools, and build from there? I haven’t heard of people having to reshuffle directories around prior to building, though I don’t normally use makepanda so I’m not necessarily in touch with the public-facing build process. But I just checked it out right now, and it appears that a normal cvs checkout puts everything in the right place, with the exception of the thirdparty tools which necessarily come from another source. But the INSTALL-MK document seems to explain all this pretty well.
Hmm, it sounds like you never saw the INSTALL-MK document. This is mentioned on the manual page: Building Panda from Source.
I see now that there is another manual page called “Tutorial: Compiling the Panda 3d Source on Windows” that doesn’t mention this document. I’ve just corrected this oversight.
That one’s my fault. I’d just added this new directory yesterday, and failed to update makepanda.py with the new build rules for it. My apologies.
Dtool_PythonTask is generated by interrogate; if you don’t have that symbol, something is very wrong. Are you seeing interrogate run on each directory?
An interesting aspect of problem #1 is that anything I compile with MSVC currently has this problem, not just Panda3D. I don’t recall having this problem before, and AFAIK I haven’t reconfigured MSVC since I last compiled something in it. The MSVC help page for this error claims I need to update “dbi.dll” so it can support the .pdb file. This doesn’t make sense unless I’m using existing .pdb files (which I’m pretty sure is not the case for my own projects), and with a quick google for dbi.dll I found a page mentioning a dbi.dll that is a Python extension. Hence my conclusion that these might be completely different libraries with the same DLL name, which has the potential to confuse Windows to the point of LoadLibrary() selecting the wrong DLL and reusing the already loaded one.
My CVS knowledge is probably too limited for me to check out your build tree properly (I’m more accustomed to svn). What I did was check out each of the folders under the root as a separate module, since WinCVS kept nagging me until I specified a module name with each checkout, that name then becoming one of the directories under the CVSROOT. Makepanda refused to build until I moved the contents of some of these directories into the build root. What would a normal checkout look like?
That explains it then. I was indeed following the tutorial at first. I did find the install docs (INSTALL-MK and INSTALL-PP), but only after getting nagged by Makepanda about missing packages.
Not that I can tell, no. When is this supposed to happen?
I did end up with a functioning Panda3D build, though, and the skeleton generation / animation stuff works fine.
I’m generating a complete build log. Hopefully it’ll provide some clues. Might take a while, though.
By the way. I just fixed the pgraphnodes bug, if you do a “cvs update” in the “makepanda” and “panda/src/pgraphnodes” directories, it will be fixed.
You should actually be checking out the “panda3d” dir as module:
cvs -d:pserver:anonymous@panda3d.cvs.sourceforge.net:/cvsroot/panda3d co -P panda3d
The build log from the hand-merged tree shows that interrogate is indeed being run on several directories (though I don’t know if it’s all of the required ones). If I add back the import line for Dtool_PythonTask to pythonTask.cxx and make sure it is being referenced from within a function, then I still get the unresolved reference. This could be a consequence of my manually merging CVS directories, though.
Thanks. I ditched WinCVS and used the above command line exactly, and makepanda seems to run perfectly (if I remove the /DEBUG, /Zi and /Fd options in makepanda.py, that is). I’m currently building that source tree and generating another build log.
Hmm, I don’t fully understand what’s going wrong, but I’ve just checked in a new version of pythonTask.cxx that uses the original Dtool_TypedReferenceCount, and also has all of the other recent fixes. (There’s no reason to require the use of Dtool_PythonTask.)
Yes, now the build completes without any source code modifications.
I don’t mind helping you dig deeper for the problem, if you’re interested. I’m not sure what to look for, though, and would prefer not having to analyze the complete build process in detail to figure out how the missing symbol should get created.
Until I get severe storage space problems or they are no longer needed, I’ll be keeping the build logs from all three builds, as well as both build trees (the hand-merged one, which still has the error, and the clean and updated one, which builds without errors).
Thanks, though don’t go out of your way. I’m satisfied with this for now. I assume the actual problem is due to some build order issue that’s slightly different between makepanda and ppremake. That makes it a very minor problem, and probably more trouble than it’s worth to research completely, especially because this workaround solves the problem.