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