gem again

Guenter Geiger geiger at epy.co.at
Mon Sep 27 15:30:48 CEST 1999


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




More information about the Pd-list mailing list