I'm surprised that there is any problem with this...it is extremely 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.
Later, Mark
============================ = mdanks@stormfront.com = http://www.danks.org/mark ============================
-----Original Message----- From: 19.ItX_IWZw.540.87 [mailto:opt@web.fm] Sent: Sunday, September 26, 1999 1:32 PM To: Michael A. Thompson Cc: pd-list@iem.mhsg.ac.at Subject: Re: gem again
the problem seem to be, on linux, newer version of egcs (2.9.x) and also glibc version and with which version of egcs/gcc the glibc was compiled.
the error i get from Gem on load seem to be unitialized variables: undefined symbol: _6GemMan.m_shininess or undefined symbol: _6GemMan.m_windowState
grml
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?
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?
grnx
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
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 ?
well, it would be good to know beforehand because i dont want to CHANGE COMPILER, its 3 times hell + back ..
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 ?
naja, new with this f**ing suse thing .. oke, /usr/X11 is linked to X11R6 anyhow, so thats 'wurscht', but at least 'normally' (other distribs) the include files hang out in usr/X11/include/X11 i think ..
-
59.xbWR>X_wiT.461.75 -
Guenter Geiger -
Mark Danks