under the other topic, interrogate crash, I’ve so far described my adventurous journey of getting panda to build with MSVC8 aka Visual Studio 2005. As by now I’m in the realm of pure MSVC8 problems, I’ve opened a new thread.
My last problem was that the linker couldn’t find libc.lib. It turns out that MSVC8 doesn’t have any libc.lib anymore - because MS dropped support for the single-thread runtime with version 8.
The recommended remedy is to add the linker switch /nodefaultlib:libc.lib.
After making the necessary changes in makepanda.py, I get over this problem, but a new one hits:
freetype complains about two undefined externals, __pctype and ___mb_cur_max. Some research tells me that this is a result of /nodefaultlib:libc.lib.
Looks like a no-win situation.
Anyway, someone else (in a context different from building panda) with the same problem got away with putting
You could try putting it in dtool/src/dtoolbase/dtoolbase.cxx. This file is linked with every file that is compiled as part of the Panda system. If it needs to be in a header file, you could try dtoolbase_cc.h: this file is #included into every file.
With either of these two approaches, you don’t need to add anything to makepanda. But for the record, makepanda is just a simple Python program: you can open it up and take a look at it, and it should be pretty clear from inspection how you can add files to it.
Trying it, it turned out that eg dtool is already configured in such a way to avoid all these problems - so if I add the lines as suggested, dtool won’t build because now we have duplicate definitions. That gave me the idea that the problem maybe only lies with the prebuild freetype library which I downloaded of your website. So I got myself the source for freetype and built it myself, making sure to use the multithreading runtimes, then renamed and copied the lib to the right location, same with include files.
Now that seems to fix that problem - so after all it was only freetype having been built with the singlethreaded runtime.
Next smaller bump on the road:
\panda3d\panda\src\egg\lexer.cxx.prebuilt is again one of those files checked in with Mac lineendings.
After converting that, I get all kinds of compile-time errors with the code in lex.yy.c - but I need to do a rebuild now, maybe some of my tinkering hasn’t been detected as a changed dependency.
Okay, problem solved, Visual Studio is just plain stupid when it tries to convert a file with mixed line-endings: it just makes a CR/LF out of any CR or LF it encounteres, effectively doubling the number of lines, thus adding blank lines between any code line - bad thing for macros which is why the standard lexer code wouldn’t compile.
Next problem is another compile-time error:
<localPandaHome>\panda3d\panda\src\egg\eggXfmSAnim.cxx(203) : error C2440: 'initializing' : cannot convert from 'const char *' to 'char *'
Conversion loses qualifiers
I’ll check it out and post what’s the deal with that.
If I make p a const char*, the compiler doesn’t complain anymore.
The weird thing is that there are overloads for strchr for all possible combinations of const or non-const arguments returning const or non-const char* - so why did the compiler not just pick the overload returning a non-const char*?
Anyway, next thing is
\panda3d\panda\src\framework\rock_floor.rgb.c
again has MAC line-endings - I note all the files of that kind here, so you can fix them in CVS to save future folks the hassle.