Makepanda cannot function without interrogate. It’s on the todo list.
Oh, oops. Well, you can try to go back to ppremake, or I guess you can tough it out with running interrogate. But one wonders why interrogate is parsing glext.h. Can you show me the interrogate command line that is failing?
Actually, I haven’t used gcc 3.3 yet. I’m on an earlier version of gcc; I don’t remember what it is offhand.
David
cd panda/src/glxdisplay ; ../../../built/bin/interrogate -DCPPPARSER -D__STDC__=1 -D__cplusplus -D__ppc__ -D__const=const -Dvolatile -D__BIG_ENDIAN__ -D__inline__=inline -D__GNUC__ -S../../../built/include/parser-inc -S/usr/include -I../../../built/python/include -oc ../../../built/tmp/libglxdisplay_igate.cxx -od ../../../built/pandac/input/libglxdisplay.in -fnames -string -refcount -assert -python -I../../../built/tmp -I../../../panda/src/glxdisplay -I../../../panda/src/gobj -I../../../built/include -DBUILDING_PANDAGLUT -module pandagl -library libglxdisplay glxGraphicsPipe.h
*** Error in ../../../built/include/glext.h near line 2850, column 137:
parse error
Error parsing file: 'glxGraphicsPipe.h'Interesting. I now see that (a) interrogate is indeed configured to run in the glxdisplay directory, and (b) it is pulling in glext.h, even on my Windows system. I’m not entirely sure why you’re crashing and I’m not, but I bet OSX defines some system flag in GL/gl.h, for instance, that slightly changes the behavior of glext.h.
But the bottom line is that I still think it’s a mistake to be running interrogate here at all. There’s no reason for it. There used to be a reason, a long time ago, and I guess we never took out the command to do it.
So the easiest way to fix it may be to locate the command to run interrogate on the glxdisplay directory in makepanda.py, and remove it or comment it out. This is line 4568 in my version of makepanda.py. Josh, is this all we need to do to make interrogate not run on this directory?
David
taking that out has allowed compilation to proceed a little further… now GCC is trying to allocate 1.8GB (in one block, on top of an already massive memory footprint) to compile parser.yxx 
/me looks up that --low-memory flag for GCC
Can’t find anything about that anywhere. Tried switching from GCC 3.3 to GCC 4.0 (which has a much improved C++ parser), but it’s also much pickier about not compiling illegal code. This is the result, if it means anything to anyone 
gcc-4.0 -c -o built/tmp/dtoolutil_gnu_getopt.o -I"/usr/include/python2.3" -Ibuilt/tmp -Idtool/src/dtoolutil -Ibuilt/include -O2 -DBUILDING_DTOOL dtool/src/dtoolutil/gnu_getopt.c
gcc-4.0 -c -o built/tmp/dtoolutil_gnu_getopt1.o -I"/usr/include/python2.3" -Ibuilt/tmp -Idtool/src/dtoolutil -Ibuilt/include -O2 -DBUILDING_DTOOL dtool/src/dtoolutil/gnu_getopt1.c
g++-4.0 -ftemplate-depth-30 -c -o built/tmp/dtoolutil_composite1.o -I"/usr/include/python2.3" -Ibuilt/tmp -Idtool/src/dtoolutil -Ibuilt/include -O2 -DBUILDING_DTOOL dtool/src/dtoolutil/dtoolutil_composite1.cxx
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h: In member function `void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::destroy_node(std::_Rb_tree_node<_Val>*) [with _Key = std::string, _Val = std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >, _KeyOfValue = std::_Select1st<std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > > >, _Compare = std::less<std::string>, _Alloc = pallocator<pmap<std::string, std::string, std::less<std::string> > >]':
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:1076: instantiated from `void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_erase(std::_Rb_tree_node<_Val>*) [with _Key = std::string, _Val = std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >, _KeyOfValue = std::_Select1st<std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > > >, _Compare = std::less<std::string>, _Alloc = pallocator<pmap<std::string, std::string, std::less<std::string> > >]'
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:568: instantiated from `std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::~_Rb_tree() [with _Key = std::string, _Val = std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >, _KeyOfValue = std::_Select1st<std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > > >, _Compare = std::less<std::string>, _Alloc = pallocator<pmap<std::string, std::string, std::less<std::string> > >]'
dtool/src/dtoolutil/pandaSystem.cxx:33: instantiated from here
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:387: error: no matching function for call to 'pallocator<pmap<std::string, std::string, std::less<std::string> > >::destroy(std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >*)'
/usr/include/gcc/darwin/4.0/c++/ext/new_allocator.h:105: note: candidates are: void __gnu_cxx::new_allocator<_Tp>::destroy(_Tp*) [with _Tp = pmap<std::string, std::string, std::less<std::string> >]
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h: In member function `void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::destroy_node(std::_Rb_tree_node<_Val>*) [with _Key = std::string, _Val = std::pair<const std::string, std::string>, _KeyOfValue = std::_Select1st<std::pair<const std::string, std::string> >, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]':
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:1076: instantiated from `void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_erase(std::_Rb_tree_node<_Val>*) [with _Key = std::string, _Val = std::pair<const std::string, std::string>, _KeyOfValue = std::_Select1st<std::pair<const std::string, std::string> >, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]'
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:568: instantiated from `std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::~_Rb_tree() [with _Key = std::string, _Val = std::pair<const std::string, std::string>, _KeyOfValue = std::_Select1st<std::pair<const std::string, std::string> >, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]'
dtool/src/dtoolutil/pandaSystem.cxx:220: instantiated from here
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:387: error: no matching function for call to 'pallocator<std::string>::destroy(std::pair<const std::string, std::string>*)'
/usr/include/gcc/darwin/4.0/c++/ext/new_allocator.h:105: note: candidates are: void __gnu_cxx::new_allocator<_Tp>::destroy(_Tp*) [with _Tp = std::string]
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h: In member function `std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_create_node(const _Val&) [with _Key = std::string, _Val = std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >, _KeyOfValue = std::_Select1st<std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > > >, _Compare = std::less<std::string>, _Alloc = pallocator<pmap<std::string, std::string, std::less<std::string> > >]':
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:787: instantiated from `typename std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, const _Val&) [with _Key = std::string, _Val = std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >, _KeyOfValue = std::_Select1st<std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > > >, _Compare = std::less<std::string>, _Alloc = pallocator<pmap<std::string, std::string, std::less<std::string> > >]'
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:881: instantiated from `std::pair<typename std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator, bool> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::insert_unique(const _Val&) [with _Key = std::string, _Val = std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >, _KeyOfValue = std::_Select1st<std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > > >, _Compare = std::less<std::string>, _Alloc = pallocator<pmap<std::string, std::string, std::less<std::string> > >]'
/usr/include/gcc/darwin/4.0/c++/bits/stl_map.h:360: instantiated from `std::pair<typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::iterator, bool> std::map<_Key, _Tp, _Compare, _Alloc>::insert(const std::pair<const _Key, _Tp>&) [with _Key = std::string, _Tp = pmap<std::string, std::string, std::less<std::string> >, _Compare = std::less<std::string>, _Alloc = pallocator<pmap<std::string, std::string, std::less<std::string> > >]'
dtool/src/dtoolutil/pandaSystem.cxx:220: instantiated from here
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:365: error: no matching function for call to 'pallocator<pmap<std::string, std::string, std::less<std::string> > >::construct(std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >*, const std::pair<const std::string, pmap<std::string, std::string, std::less<std::string> > >&)'
/usr/include/gcc/darwin/4.0/c++/ext/new_allocator.h:101: note: candidates are: void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, const _Tp&) [with _Tp = pmap<std::string, std::string, std::less<std::string> >]
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h: In member function `std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_create_node(const _Val&) [with _Key = std::string, _Val = std::pair<const std::string, std::string>, _KeyOfValue = std::_Select1st<std::pair<const std::string, std::string> >, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]':
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:787: instantiated from `typename std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, const _Val&) [with _Key = std::string, _Val = std::pair<const std::string, std::string>, _KeyOfValue = std::_Select1st<std::pair<const std::string, std::string> >, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]'
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:901: instantiated from `typename std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::iterator std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::insert_unique(std::_Rb_tree_iterator<_Val>, const _Val&) [with _Key = std::string, _Val = std::pair<const std::string, std::string>, _KeyOfValue = std::_Select1st<std::pair<const std::string, std::string> >, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]'
/usr/include/gcc/darwin/4.0/c++/bits/stl_map.h:384: instantiated from `typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::iterator std::map<_Key, _Tp, _Compare, _Alloc>::insert(typename std::_Rb_tree<_Key, std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::iterator, const std::pair<const _Key, _Tp>&) [with _Key = std::string, _Tp = std::string, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]'
/usr/include/gcc/darwin/4.0/c++/bits/stl_map.h:339: instantiated from `_Tp& std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with _Key = std::string, _Tp = std::string, _Compare = std::less<std::string>, _Alloc = pallocator<std::string>]'
dtool/src/dtoolutil/pandaSystem.cxx:242: instantiated from here
/usr/include/gcc/darwin/4.0/c++/bits/stl_tree.h:365: error: no matching function for call to 'pallocator<std::string>::construct(std::pair<const std::string, std::string>*, const std::pair<const std::string, std::string>&)'
/usr/include/gcc/darwin/4.0/c++/ext/new_allocator.h:101: note: candidates are: void __gnu_cxx::new_allocator<_Tp>::construct(_Tp*, const _Tp&) [with _Tp = std::string]I can help with both issues.
With gcc 3.3, this is no doubt a bug that GCC gets from time to time with regards to its optimizer. You could compile parser.cxx without optimizations; there’s probably a way to coerce makepanda.py to do this for this one file. Or you can cheese it out by running the compile command by hand on this one file (without the -O2 option), and then running the script again to carry on.
With gcc 4.0, it’s mad because they have changed (again) the definition of the STL allocator class. Easy workaround is to tell Panda not to try to use the allocator. There’s a series of #defines in makepanda that look like this:
#undef OLD_STYLE_ALLOCATOR
#define GNU_STYLE_ALLOCATOR 1
#undef VC6_STYLE_ALLOCATOR
#undef MODERN_STYLE_ALLOCATOR
#undef NO_STYLE_ALLOCATORChange them to look like this instead:
#undef OLD_STYLE_ALLOCATOR
#define GNU_STYLE_ALLOCATOR
#undef VC6_STYLE_ALLOCATOR
#undef MODERN_STYLE_ALLOCATOR
#undef NO_STYLE_ALLOCATOR 1David
That does fix the first error, but it errors out with a very similar message later.
Going back to GCC 3.3 now. Can’t see how to turn off optimization for the one file in makepanda.py, so will try that one compile by hand.
Now I’m getting this:
g++-3.3 -framework CoreFoundation -o built/bin/pview -Lbuilt/lib built/tmp/pview_pview.o -lframework -lpanda -lpandafx -lpandaexpress -ldtoolconfig -ldtool -lpystub
ld: Undefined symbols:
_panda_version_1_0_3Sure enough, panda_version_1_0_3 doesn’t appear to be defined anywhere, though it’s extern’d in a few places. Where should this be?
This symbol is defined explicitly for the purpose of verifying that you are linking libpanda with its matching version of libdtool. It is defined in dtool/src/dtoolutil/checkPandaVersion.cxx, which (along with the matching checkPandaVersion.h) is a generated file.
Make sure you aren’t inadvertently including header files from the wrong tree somewhere; also make sure you haven’t changed panda versions halfway through your build. It might be a good idea to start a clean build from scratch if there is any doubt.
David
EXPCL_DTOOL int panda_version_1_0_3c = 0;Any clues where the extra c might come from?
By convention, the “c” indicates the tree was built by the user, as opposed to an official version built by us. I considered this worth noting in the version number because a tree checked out by the user might not exactly match the 1.0.3 version across the board.
David
So why would the rest of the code be trying to use the un-c’d version?
It must be a mismatched compilation. If the symbol name defined in the header file matches the one in the cxx file, then the problem files must have been compiled with a different header file.
Either an earlier version that was built differently for some reason, or they are picking up the header file that is installed in /usr/local/panda or whatever.
David
The build is from clean (well, rm -rf built, anyway), and there’s nothing in /usr/local/panda – perhaps there’s something I could have screwed up in makepanda.py?
Hmm. The symbol panda_version_* should really only appear in two places: checkPandaVersion.h and checkPandaVersion.cxx. You mentioned in an earlier post in this thread that it was externed in a few places. Is it actually being externed in other places, or is it just that the other code is including checkPandaVersion.h?
It might be useful to grep for this symbol in your .so files, and see where it’s coming out wrong:
nm libdtoolutil.so | grep panda_version_
nm libpanda.so | grep panda_version_
nm libpandaexpress.so | grep panda_version_
And so on. You can also grep in the .o files:
nm pview_pview.o | grep panda_version_
Someone, somewhere must have picked up the wrong panda_version symbol.
David
keith$ find . -name '*.dylib' | xargs nm -A | grep panda_version_
./built/lib/libdtool.dylib:dtoolutil_composite1.o: 00065008 D _panda_version_1_0_3c
./built/lib/libframework.dylib:framework_config_framework.o: U _panda_version_1_0_3
./built/lib/libpanda.dylib:panda_panda.o: U _panda_version_1_0_3
./built/lib/libpandaegg.dylib:pandaegg_pandaegg.o: U _panda_version_1_0_3
./built/lib/libpandaexpress.dylib:pandaexpress_pandaexpress.o: U _panda_version_1_0_3
./built/lib/libpandafx.dylib:pandafx_pandafx.o: U _panda_version_1_0_3
./built/lib/libpandagl.dylib:pandagl_pandagl.o: U _panda_version_1_0_3
./built/lib/libpandaphysics.dylib:pandaphysics_pandaphysics.o: U _panda_version_1_0_3IOW, only the one place thinks it should have a c; everyone else is convinced it shouldn’t…
These other libraries are the ones that are in the panda tree; only the one in the dtool tree has it right. That strongly suggests there is some errant checkPandaVersion.h file out there that the panda tree is picking up.
Does OSX have the locate command?
locate checkPandaVersion.h
David
It does, but it also has Spotlight, which is better 
I have two checkPandaVersion.h files, both within the one panda source tree –
dtool/src/dtoolutil/checkPandaVersion.h says: extern EXPCL_DTOOL int panda_version_1_0_3c;
built/include/checkPandaVersion.h says: extern EXPCL_DTOOL int panda_version_1_0_3;
so that’s where the conflict comes from, at least.
OK, the problem is that you used both build systems: ppremake, and makepanda. The two aren’t compatible with each other. If you decide to switch from one build system to the other, you need to get a clean source tree.