59.xbWR>X_wiT.461.75 writes:
vanilla C++. It doesn't look like uninitialized variables, but rather that the linker can't find the symbol references in the look up table...strange.
Look in GemMan.cpp around line 45 to see the declarations.
yeah, i looked into it .. when you change for example GLfloat GemMan::m_mat_shininess; into GLfloat GemMan::m_mat_shininess[somenumber]; to be an array as in the lines above, no error occurs on loading .. but the next var in GemMan.h in the private section right at the end ( static int m_windowState;) pops up (ok, maybe thats obvious to some of you, i m just playing t+e ;) it doesnt change any if you make them public thou .. variable initialization kaputt?
It´s nothing about initialisation, it´s just that it seems that the symbols got lost somehow. I think you should switch to another compiler. Or, could it be a problem with the linker ?
for linux (gem/src/Gnu) another thing i notice now, is that the make doesnt really wanna work. when you change gem's source files and just do a make again, it doesnt relink the Gem.pd_xxx binary.?
also, to get X found, i need to ./configure --x-libraries=/usr/X11R6/lib --x-includes=/usr/X11R6/include whihc are in fact fairly obvious places?
huh ... a bug in autoconf ? is this behaviour new ?
Guenter