while i am trying to build from panda source tree, i met strange errors which I guess are due to compiler’s c++ conformance discrepancy from what was used by the panda development team. i am working with vc++ 2003 in cygwin environment.
i think (but not so sure) this works in vc++ 2002 comiler which has less strict conformance with iso c++ standard. is there anybody who succeeded to compile panda with the same environment as mine?
so the above message didn’t get a response, but i think i am having a related problem… i compile dtool fine, but compiling panda i immediately get this error, with the latest .Net 2003 compiler (the one with the completely overhauled template support and stricter standards compliance.) this looks exactly like the kind of problem that comes from slightly noncompliant code when you try to build in .net 2003. oh, this is with the latest downloadable source drop of panda (not the latest directly out of CVS, though, i’m not that bold.)
Hmm. It actually looks to me like the compiler is a little confused. It is correctly reporting that the typename keyword cannot be used outside of a template declaration, yet the code at line 720 of ordered_vector.I is very clearly within a template declaration, where the typename keyword is required.
But I have never been one to argue with an upset compiler. There are two occurrences of the typename keyword near line 720 on ordered_vector.I: one on line 720 itself, and one on the following line (we define a macro TYPENAME in all uppercase to stand in for the actual typename keyword; don’t let the case trouble you).
I’d suggest trying to remove the keyword on line 720 first, and if that doesn’t work, then try to remove the one on line 721. If removing one or the other satisfies the compiler, please let us know so we can make the same adjustment in the official source tree–and if necessary, protect it in an #ifdef so it doesn’t break other compilers that do expect a keyword there.
okay, great, thanks! i guess what i mostly wanted to know was how tested panda3d was under .net 2003; if every developer under the sun was using .net 2003 already i’d be more concerned about this compilation stuff.
i’ll give that a shot and then keep plugging away at it if any other errors come up. assuming i manage to get it working, i’ll post (or zip and post a link to, if they’re big) the diffs against the drop i’m using now, and someone else can see if my changes are iso-compliant and could be merged back into the trunk.
okay, so, first, i’m a fool. i’d installed MSVC6 more recently than .net 2003 and my environment variables were such that it was actually compiling with the msvc6 compiler, which is super-old.
once i fixed it to use the .net 2003 compiler that error went away and has been replaced by a far more perplexing one that i spent a few hours on a plane flight looking at just now, but could not really figure out what the compiler wanted me to do:
i’ve pasted the exhaustive–but actually very helpful–compiler error message in below. at least the template compilation errors are much more informative in .net 2003.
the deal is, class pallocator inherits from allocator, and within allocator is:
… which is not behavior i am familiar with (scoped, inheritance-overriden typedefs within nested structs go beyond the C++ functionality i regularly employ.)
anyway, the compiler is complaining that when another STL template refers to the allocator::rebind::other, it’s trying to access an “inaccessible typedef”, although the typedef is obviously publicly declared in the struct and the struct itself is declared in the public scope of pallocator. and i was unable to determine why else it might be considered “inaccessible” (so for all the verbosity, the compiler error message left that one detail to be desired.)
any ideas? i’d appreciate any info at all, since i’m pretty stymied.
Ah, and this appears to be the same problem that vexed the original poster. If you’re still around, simplyk, there is a very simple workaround: just put the following in your Config.pp file.
#define STL_ALLOCATOR UNKNOWN
Background information: STL, the so-called “standard” template library, provides a feature called an allocator, which is used to control how new nodes are allocated from the C++ heap. However, each different compiler we have ever used to build Panda has employed a subtlely different way to implement this allocator; each method is similar in basic structure to the others and yet completely incompatible, with the result being an enormous and completely obtuse error message just like this one should you try to use the wrong version.
You can see some of the legacy of these different approaches in the different implementations supported within dtool/src/dtoolbase/pallocator.h.
I’d hoped that we’d finally reached the end of this chaos, but I guess it is not to be yet. Fortunately, the STL allocator is only used to support a quite esoteric feature of Panda–the ability to track how much application memory has allocated by the Panda engine itself, for tuning. You can safely do without this feature, and never miss it; and that’s what happens when you put the indicated line in your Config.pp file.
Shoot. The compilerSettings.pp file was designed by a programmer here who didn’t fully understand how the .pp files in dtool were supposed to work with the user’s personal Config.pp file, so some things aren’t quite right.
Still, looks like there’s another workaround there. Instead of directly modifying STL_ALLOCATOR, you can define: