> Derek Lamb writes additionally: > ... > > > Oops, I think you should have prepended here rather than replace the > > entire set of directories. As is, unless all of the required > > libraries and include files are in ~/local, you'll be missing a lot: > > i.e. > > libGL, libGLU, ... > > > ok. I was confused about the relations between > GL, GLU, GLUT, FreeGLUT, etc... I thought they were > all different implementations of the same libraries, > but apparently that's not the case.
GLUT actually requires GL and GLU to link. > ... > > > Do you have freeglut_std.h in your include directories? > > > yes, it is in ~/local/include/GL/. Though I noticed that > GLUT_INIT_STATE was in freeglut_ext.h, not freeglut_std.h. I also found > the following interesting relationship among the header files in that > directory: > $ grep '#include' ~/local/include/GL/* > /home/dlamb/local/include/GL/freeglut.h:#include "freeglut_std.h" > /home/dlamb/local/include/GL/freeglut.h:#include "freeglut_ext.h" > /home/dlamb/local/include/GL/freeglut_std.h:#include <GL/gl.h> > /home/dlamb/local/include/GL/freeglut_std.h:#include <GL/glu.h> > /home/dlamb/local/include/GL/glut.h:#include "freeglut_std.h" > > freeglut.h #includes _std & _ext, but glut.h only #includes > freeglut_std.h. So I changed line 4 of glut_util.h to > #include <GL/freeglut.h> > and that got rid of the GLUT_INIT_STATE warning, and allowed make to > complete seemingly without errors. It looks like FreeGLUT moved the defines from freeglut_std.h to freeglut_ext.h. A lot depends on the distribution which may choose to make glut.h a link to freeglut.h. As you might imagine, this kind of installation and platform dependent configuration stuff is tricky to sort out---and to get right without many test plaforms. > $ make test > fails with > t/00_require....1/1 > # Failed test 'require OpenGL;' > # at t/00_require.t line 3. > # Tried to require 'OpenGL'. > # Error: Can't load > '/home/dlamb/.cpan/build/OpenGL-0.59-DAL/blib/arch/auto/OpenGL/OpenGL.so' > for module OpenGL: > /home/dlamb/.cpan/build/OpenGL-0.59-DAL/blib/arch/auto/OpenGL/OpenGL.so: > undefined symbol: glClampColorARB at > /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230. If GL_ARB_color_buffer_float is in the glversion.txt output then I'm not sure what is going on here. Is it possible that there are more than one set of OpenGL, GLUT, GLU libraries on your system? The purpose of the glversion program is to probe the build-time OpenGL extensions that you have. One possibility is that the glversion is built with a different OpenGL from the OpenGL.pm module bindings. Another possibility is that the logic for the test is not correct. A third possibility is that the OpenGL configuration for the glversion program execution is different than that of the test.pl use and require tests. > and similarly for the 01_use test. Though when I run "$perl -Mblib > test.pl" I get a rotating cube with teapots that responds to the arrow > and 's' keys, at least (I don't remember the other commands from last > time). Lots of errors about "freeglut (test.pl): font 0xce281ec0 not > found"--I think I remember seeing something about that on the list before. Yes, someone else reported the problem, on another 64-bit linux install. It looks like the fonts are installed correctly but there could be a problem with FreeGLUT or even the OpenGL.pm bindings. Any clues would be appreciated. Also, what is your perl -V, and OpenGL configurations (video card, driver version, glversion.txt output, ...). > > > > If anything comes up w.r.t. 64-bit linux libraries, > > please let me/us know so that I can fix. Thanks! Your help debugging is greatly appreciated. Without debugging it is unlikely that the 64-bit support can be sorted out before the first release of the new TriD code in PDL-2.4.5. Thanks, Chris
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
